We have two different Progressive Web App projects and they are using IndexedDB for manipulating data.
We need to share data between these apps but IndexedDB seems to allocate separate storages in Browser for different apps.
I wonder how we can achieve this using PWA?
Any recommendation would be appreciated.
In general, the storage model for the web platform in general (not specific to progressive web apps) assumes that origins are boundary points, and that two web apps from different origins can't read each other's storage.
If you have two different web apps and you would like to ensure that they have access to each other's storage, the easiest approach would be to host them both on the same origin under two different URL prefixes, like https://example.com/app1/ and https://example.com/app2/.
If that approach doesn't work, then instead of relying on local storage like IndexedDB, you should consider using a remote backend storage solution. That would allow the same user across multiple web apps to authenticate and access the same remote storage.
Related
I'm planning to make web application which allows users to upload music/audio files and host them etc, i'm wondering what the best method would be to go about this, i have used cloudinary in previous projects for image hosting but nothing for audio.
What do companies like Soundcloud use if not there own service which i am assuming is the case.
What would you recommend? It will be vital when it comes to building a scalable and reliable service so I don't want to go into this project uneducated.
ps. I will be using meteor and mongodb to build the application.
I'd recommend getting started with edgee:slingshot in your app. It's much lighter on your Meteor server since uploads and downloads go straight to the storage system. There you have several choices including S3, Google Cloud Storage, and Rackspace Cloud. You could also use CollectionFS but slingshot seems architecturally better suited to this class of problem.
I have a php app running on several instances of Google Compute Engine (GCE). The app allows users to upload images of various sizes, resizes the images and then stores the resized images (and their thumbnails) in the storage disk and their meta data in the database.
What I've been trying to find is a method for storing the images onto Google Cloud Storage (GCS) through the php app running on GCE instances. A similar question was asked here but no clear answer was given there. Any hints or guidance on the best way for achieving this is highly appreciated.
You have several options, all with pros and cons.
Your first decision is how users upload data to your service. You might choose to have customers upload their initial data to Google Cloud Storage, where your app would then fetch it and transform it, or you could choose to have them upload it directly to your service. Let's assume you choose the second option, and you want users to stream data directly to your service.
Your service then transforms the data into a different size. Great. You now have a new file. If this was video, you might care about streaming the data to Google Cloud Storage as you encode it, but for images, let's assume you want to process the whole thing locally and then store it in GCS afterwards.
Now we have to get a file into GCS. It's a PHP app, and so as you have identified, your main three options are:
Invoke the GCS JSON API through the Google API PHP client.
Invoke either the GCS XML or JSON API via custom code.
Use gsutil.
Using gsutil will be the easiest solution here. On GCE, it automatically picks up appropriate credentials for your service account, and it's got several useful performance optimizations and tuning that a raw use of the API might not do without extra work (for example, multithreaded uploads). Plus it's already installed on your GCE instances.
The upside of the PHP API is that it's in-process and offers more fine-grained, programmatic control. As your logic gets more complicated, you may eventually prefer this approach. Getting it to perform as well as gsutil may take some extra work, though.
This choice is comparable to copying files via SCP with the "scp" command line application or by using the libssh2 library.
tl;dr; Using gsutil is a good idea unless you have a need to handle interactions with GCS more directly.
How to auto sync the images and video from the app into the Api Web services.
Do we have any tutorials or source codes on this.
Thanks in advance!!!
There can be multiple approaches depending upon what you are trying to achieve and what backend you are using.
If you are using simple API web services, you need to write your own mechanism both on server as well as client side, which will identify records to be synced based on TimeStamp and few other columns in your DB
If you are open to use other Platforms like Parse.com, they provide in built APIs and libraries to take care of syncing logic
As you are trying to sync file(Images and Videos), you can also try DropBox, iCloud, or Google Drive. Here is a link to an article which i found in a quick search which uses CoreData and Dropbox
Let me know if this helps.
I'm trying to create a back-end in which I can have many users communicate with each other amongst an iPhone app I'm creating. I've tried working with Core Data, Google App Engine, Google Cloud Storage, and Amazon Web Services (RDS & Elastic Beanstalk). Unfortunately, after weeks of trying to get any of this working, none of it will!
I've been trying to get in touch with someone who would know how startups (when they were little) like Instagram, Path, and Pinterest have managed to do this. But everyone out there seems to despise this stuff as much as I'm growing to...
I would love for someone to simply map out EXACTLY how I need to create a back-end database that I can save and query data to and from that many users can see. That means that just SQLite, Core Data, or Parse by itself isn't going to work here!
A tutorial of some kind would be incredible.
First off, technologies like CoreData and sqlite are typically local device storage. Local device storage is not going to get you shared cloud storage.
Parse.com is a fast way for devices to access cloud storage and get going fast. Especially useful for games and other mobile apps to access cloud data via an app id and app key. It's simple storage to avoid creating your own backend if it fills all your needs and requirements.
When you get to a multi-tenant cloud backend where you roll your own services and multiple devices accessing your cloud application you need to look into exposing your web API. Exposing RESTful API over http is great for devices and web clients. Exposing the data as JSON is especially conventient for the web and easily consumed by devices.
Those web service end points in the cloud access some sort of backend storage which is optimized for concurrent access by mutliple clients. This is typically a SQL backend like MySQL, SQLServer etc... or a NoSQL solution like mongodb, couchDB, etc...
Some front end web api technologies to look into:
ASP.net web api
Ruby on Rails
Node.js
etc...
Some back end storage technologies to look into:
SQL: MySQL, SQLServer/Azure SQL, Oracle
NoSQL: MongoDb, CouchDb, Amazon S3 simple storage, etc...
If the data is used by many many multi-tenant clients, the backends can scaled up (larger and larger) or get sharded. Sharding is where the data for multiple users is split into many databases or datastores with some sort of lookup algorithm for requests to find where that users data is stored. The front end web api servers abstract the backend storage.
Finally, you'll end up needing some sort of caching/fast lookup technology (if you're successful :):
Redis: fast in memory storage over sockets
memcached: facebook uses - simple key value in memory caching across many front end servers.
Your question is an open ended up broad question so start by googling many of these terms and technologies.
Each of these links will have resources and tutorials. Get a cloud VM, play with each and decide which fits your needs best. There is no one size fits all solution.
In search of a 'Cloud Content Management System' like http://osmek.com/,
I could not find a single other CCMS that does what I want it to do :)
Basically, what I need is content management without a website frontend attached.
Just basic storage of data, documents, images, etc. etc. with a simple API to access, like Osmek. Just NoSQL or SQL based services won't do, because there can be images or documents attached. And, ofcourse, I'd like to have a backend to manage the data (like a typical CMS does) without writing a backend myself (if it's just the service)
Osmek is great, and it works most awesome in conjunction with Actionscript 3, but I'm just looking / searching for alternatives (if there even are any yet).
I need this form of hosted content management for content-manageing a mobile application.
So the question is: Is there anything else out there that does the same as osmek that you know of? OR, how do you manage application specific content?
Thanks!
I'd encourage you to take a look at Cloud CMS (http://www.cloudcms.com).
Cloud CMS is a JSON content management (CMS) platform built on top of MongoDB with a REST API and drivers for a variety of languages. You just drop in a driver and call methods to query, create, update and delete content.
The platform provides everything you need to power the back-end for mobile and HTML5 applications - from managing your content to managing users and groups, credentials, security tokens (OAuth2), Git-like collaborative workspaces, real-time analytics, activities, data transformations and more.
Everything runs in the cloud on an elastic back-end. It's probably more akin to Parse than a traditional CMS. You just make calls to the APIs. We keep the costs low by letting you only pay for what you use (almost like a utility). You just pay for storage and data transfer.
Disclaimer: I'm one of the founders of Cloud CMS. So I'm a pretty lousy reference in terms of its objective value. However, a couple of us worked at traditional "ECM" companies in the past and we think we've built something that puts a genuine beating on those guys.