I am working on an app where I would like to allow users to bring their own cloud storage account. That is, the app needs to work with the APIs for as many cloud storage services as possible.
One feature that seems important is atomic update. The app reads a version of a file from the cloud, makes some changes, then uploads a new version. However, it needs to be able to detect if a concurrent update was made to that file (for example, if the user was concurrently logged in from a different computer). The ifGenerationMatch parameter in the Google Cloud Storage API seems to make this kind of thing possible.
Does anyone know how to accomplish it with other APIs?
Sorry to answer my own question, but I think after months of intermittent digging I found at least a partial answer in the form of a couple HTTP headers:
If-Match
ETag
Related
I am looking for a way to fetch data to my flutter app which can be adjusted and modified dynamically after deploying the app. As an example, if I want to change the images of the carousel depending on promotions or launch new books to the digital library. I need an economic option to host the data in cloud storage and fetch it from there.
I have considered firebase as well as google drive, but have yet to find a good guide. being a beginner and having concerns about security I want some expert advice if possible.
*edit-
Seeing many a tutorial I assume there is no better way than linking file URLs from the
Cloud Storage. So to dynamically change those is it possible to refer the URLs to some excel sheet fields to obtain URLs. Those fields can certainly be adjusted then without any hard coding. but the question is how to refer to such a sheet file? *
I also want to segregate the users into paid and free users, I have successfully proceeded with the authentication with firebase but still don't understand(I do have some concepts but don't know where to do that) how to put them in groups and impose limitations on them about accessing the data. any guidance, links and helpful advice will be cordially appreciated.
According to what you are looking for, I highly recommend you to use Firebase Remote Config, which is a cloud tool that allows you to modify your app's functionality and appearance without forcing users to download an update. You define in-app default values that control the functionality and appearance of your app when you use Remote Config. Then, for all app users or for subsets of your user base, you may utilize the Firebase console or the Remote Config backend APIs to modify in-app default values.
Your program can control when updates are applied, and it can check for updates regularly and apply them with minimal performance impact.
Remote Config comes with a client library that takes care of essential functions like fetching parameter values and caching them while still allowing you to manage when new values are active and how they affect the user experience in your app.
Here is a tutorial that uses Flutter and Firebase Remote Config that could also help you.
Background:
I'm building an API service app. The app is just like any other, you send an HTTP request and receive a response. This seems simple up until I start thinking about user registration, payments, authentication, logging and so on.
Application:
tl;dr simple app diagram
Endpoints listening for HTTP requests and doing all the request related work. This is the core of the service, what the service user would use this app for. Directly not accessible to the end user (unless somehow it knows the url). Python flask server, deployed on google cloud RUN.
API gateway acting like a proxy and a single access point forwarding the requests to the endpoints. This is the service access point for the end users. This part will also be responsible for authentication, limitations, logging and tracking the use of the API endpoints. Python flask server, deployed on google cloud RUN.
Website including documentation, demo and show off of API calls through API gateway, registration, payment (thinking of Stripe) etc. VueJS app on NodeJS server on google cloud compute VM.
Database storing credentials of registered users, payment information and auth keys. Not implemented yet.
Problems:
Is this architecture proper? What could be done differently or improved? How could I further simplify all the interactions between separate parts of the app? Am I not missing any essential parts?
Haven't yet implemented the database part and I'm not sure what should I
use? There are plenty of options on google cloud. Also I could go with something simple and just install a DB with http/JSON interface on google cloud compute VM. How do I chose the DB? Given such an app, what would be the best choice?
Please recommend literature/blogs/other sources of info on similar app
architecture for new developers not familiar with it?
This is pretty open ended, but here are some general comments:
Think about how your UI will work. Are you setting up a static app served directly from cloud storage or do you need something rendered on the server? Personally I prefer separating UI from API when I can but you need to be aware of things like search engine optimization. Even if you need to render some content dynamically your site can still be static. Take a look at static site generators like Gatsby. I haven't had to implement a server rendered UI in years and that makes me happy.
API gateway might be fine, but you don't really need it for anything. It might be simpler to start without it and concentrate on what actually matters. If your APIs are being called by an external client you can't trust the calls anyways and any API key you might be using will be exposed. I'd say don't worry about it for a single app. That being said, if you definitely want to use a GW then use one, just be aware that it is mostly a glorified proxy and not some core part of your architecture.
Make sure your API implementations don't store any local state so you can rely on Cloud Run scaling your services up and down. Definitely don't ever store state directly inside your containers. If you need state on the server it needs to be in some external data store.
Use JWTs or an external IDM (that will generate JWTs) for authentication. Keep session data on the client side as much as possible and pass the JWT in every API call to authenticate the caller. If you are implementing login on your own the only APIs you need to expose without tokens are for auth and password recovery, which you can separate into their own service.
Database selection depends on how well you understand your processes, how transactional your services are and your existing skillset. Overall I would use what you are comfortable with, you can probably succeed with a lot of things. Certain NoSQL flavors can seem simple on the surface but if you don't have a clear understanding on the types of queries you need to run they can get tedious to work with. Generally you should stick to relational databases for OLAP style implementations and consider NoSQL for OLTP. Personally I like MongoDB and it is very popular, probably because it sort of sits in the middle of the pack which makes it fit a lot of applications. Using MongoDB also makes you cloud agnostic since it is available on every platform. Using platform specific database flavors can lock you down to a specific vendor.
Whatever you do, don't start installing things on VMs. You can be almost 100% sure you are doing it wrong if this comes up. Remember, the services you consume don't all have to be managed by Google or even run on GCP. You can get MongoDB capacity directly from MongoDB who manage it on your behalf on all of the Big3 cloud vendors.
At least think about the long term, even if you don't necessarily need to have it impact your architecture right now. If you are expecting your app to be up for years try to make it more platform agnostic than less. This might mean sticking away from some really platform specific serverless features that will force you to jump a couple of extra hoops. If you are using Cloud Run you are using containers which already makes your app pretty portable, don't lock it to one platform by using a lot of platform specific features. That being said, don't stay away from them either. You should always go for the low hanging fruit, so don't try to avoid using things like secrets manager etc. If your app has a short lifespan and you need really fast time to market then don't worry about it.
Just my 2c, what you are doing is very generic and can be done in a lot of different ways.
AWS S3 supports lifecycles for buckets, does this work in Bluemix S3?
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putBucketLifecycleConfiguration-property
When I call it (using the aws-sdk nodejs module), I get back a 400 saying 'The operation requested is not supported'. The docs say a subset of s3 is handled but I'm not sure what ISNT't handled.
No, lifecycle configurations aren't supported at this time. The full list of supported operations is on the API overview page. If you want to, feel free to send me an email (nicholas.lange[at]ibm.com) and let me know what you are trying to do. Having developer feedback makes it easier to advocate for prioritizing new feature work.
Also, FYI, there is a new release of object storage that will be available on the IBM Cloud platform (Bluemix) soon, with IAM permissions and OAuth2 support instead of AWS signatures. The docs will migrate there shortly.
Can Google cloud storage be used in such an application without a proper http server (Traditional LAMP stack, GAE, etc.)?
If you're having a hard time wrapping your head around "static data powered application", think of it like a blog where you can only read the blog posts (i.e. no likes,comments or any kind of interaction) and which is managed by only one person who updates, adds or removes those blog posts.
The main concerns that I have are :
Read-only access from JavaScript at client side
Prevention against abuse (Does google automatically detect and ban an IP when it sends too many requests, so that the IP can't abuse bandwidth?)
I did some basic digging around the docs, but couldn't find the answer to these, possibly because not many have tried this, I guess.
The access question is already answered by Paul. You can add "read" permission to all users for your object. If you want to do so for all objects in a bucket, you can also set the default object ACL for the bucket to contain such permission.
Google does have abuse protection, but it's not designed for a specific service or resource, and the bar is pretty high given Google's global scale, so it probably won't help your specific use case.
Unfortunately you cannot set a maximum daily spending yet. The Google cloud platform team is always working on new features to help customers solve these issues, but I cannot comment on specific feature or timeline.
I've noticed that the JSON API for Google Cloud Storage is, as it says, "Experimental", and that the URL's I'm supposed to use all have 'v1beta2' in it. It looks like it hasn't been touched since May 7th, and I'm wondering if it's worth creating a new project with this service as primary storage service if I'd want my app to go live in a month or two. Is there a release date somewhere, or is it more like "it'll take as long as it takes"-kinda thing?
Please don't downvote, I wanted to ask this in Google Cloud's own forum as this isn't a programmatic question, but as it turns out - their forum is linking me here to SO asking me to tag with 'google storage' for anything related to it.
The Google Cloud Storage JSON API is marked "experimental" to mark it as an exception to our deprecation policy. As we bring it to full release, there is a chance we may make some changes to the API, and this is why you see the special URLs. We don't have a date yet for full release. You should be able to use it just fine, if you are prepared to migrate your app to the official API when it is released.