I'm developing an Ionic(3 / 4)(Angular 4 - 7)-Cordova / Capacitor Cross Platform Application(s). I'm interested in switching API env based on the current rollout track in the Google Play Store. For example, once an application has been successfully tested and recommended to continue staging/production. I would like to have the API env dynamically changed (e.g., using a different URI domain to connect to REST API ) dependent on the Google Play Store Track.
I'm aware that I can use Google Developer Play Store API to identify / list versions and available tracks yet, I'm unaware if there's already an implementation or solution. I'm perfectly willing to design a solution though, I figure I find out if it's been done already rather than reinvent the wheel.
I'm hoping to implement a solution either to the REST API BACKEND or in the ionic framework layer rather than an integration at the native layer for scalability per-project. The purpose of doing this would enable CI rather than rebuilding the project and change the API URI domain for every environment. Any assistance in this matter would be greatly appreciated.
So, if anyone's interested. The approach highlighted above is possible, couldn't get an answer so I just created something. Using Google Play Developer API. The process flow is as follows:
[]
For now it's a working prototype perhaps its not very efficient; I suppose it can be improved if the request was issued from a single server, or microservice. Though, I wanted to make the code recyclable and it's isolated from both the mobile application & Node Server.
If you are interested in learning more or would like to work on project. Please feel free to contact me.
Related
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.
I'm confused about Firebase and serverless in general, as I was just introduced to this concept recently (note that I'm still studying computer science and I'm just exploring on my own now).
In the past I've been part of a project that had the following structure:
Front End in a Single-page-app
Back End built as a REST API
Now let's say I want to build a product, that might have a website and mobile apps. It also has to have backend logic as there are accounts, objects owned by users, and possible integration with a payment service.
What I initially expected from this, before knowning about serverless, is that you build a backend using something like Go (was my case), where you handle all the database data and third-party integrations, build a front end with something like Vue, and then use the backend's REST API to communicate between both of them.
Is this still the case with serverless? Do you build the whole backend server code, or does it work in another way?
I don't need/want you to explain all of it to me. I just need some insight on what is done and common so I can investigate further.
We are developing some REST api's for internal use. To test these microservices we are toying with the idea that every service has a sandbox mode so we can do integration tests that are as close as possible to the real deal.
To see if this path is worth trying we are looking for documentation / best practices on how to manage this sandbox and how to implement this internally. When we look for the keywords Sandbox, REST API and Best Practices we only find how to implement as consumer of existing sandboxes.
So does anyone have some documentation / links in how to tackle this problem and what the pro's and con's are of the different ways?
Kr,
Thomas
I'd say there are two ways to proceed:
Basic: keep a separate sandbox instance of a service. You always deploy a new code to this instance first and run automated/manual tests to verify if everything works fine. A datastore could be a snapshot from the production data or artificial testing data. I would rather we have a "Snapshot" but it depends whether it is applicable in your particular case (privacy etc.)
Advanced: I spied this technique on Facebook Marketing API. This API provides an interface to set up and launch advertising campaigns. They didn't provide a sandbox api for testing purposes (at least last year when the system I was working on had been integrating with Facebook). However if you use a keyword "test" in a name of a campaign or an adset (key entities in the ad world) they would never launch and spend your money. You can try extend this concept on your particular domain and run tests on (or very close to) your production
Hope this helps
I am doing an android application, I'd like to know how to connect sensor devices/applications to Bluemix IoTF using API keys, by saying that I just want to minimize the registration task from client side(sensor devices)as much as possible. I know how to register devices with deivce Id,token and authentication manually. but I just like to know that is there any other easy way around to do it. It would be great If I got some one shed light on this from scratch. Thanks in advance.
There is a rich set of REST based APIs available at:
https://docs.internetofthings.ibmcloud.com/devices/api.html
and fully documented here:
https://docs.internetofthings.ibmcloud.com/swagger/v0002.html#/
One can use excellent REST based testing tools such as Postman for REST testing.
The reason I mention the REST APIs is that they provide a way for scripting or automating the registration of devices. There is an API called "Add device" that, when called, will register a new device instance of a specific device type against your IoT Foundation instance.
I could imagine a new device that knows it is not registered executing a self registration request to define itself as a new device type. What I would next suggest is that you read the links above and see if they make sense. If they answer your question fully, great. If not, simply post a new question that is specifically targeted at a specific areas and we'll be watching this set of tags and respond back as quickly as we can.
I am using OpenTokSDK for iPhone (using it Natively)
I have made the code for calling but just there is one problem.:-
I have to statically Add the SessionID. But i want to generate the ID Dynamically.
How can I do this ?
Please help!
Thanks In Advance
Full disclosure: I am a developer for TokBox.
The only safe way to get session ID and token credentials to the device is by developing an application server that suits the specific needs of your app. We have a number of server-side SDKs available on GitHub (link) that will interface with the OpenTok server API to generate this data.
Note well the server-side SDK is enough to get your credentials generated, but not all devices will be on the same session, so things like user management and application workflows are all considerations that cannot be easily written to an open source library.
That said, we did try to make some of these examples more clear by writing code examples on our blog (link). You can relieve much of the overhead of writing your own application server (no doubt a daunting task, especially the first time around) by leveraging one of the third party signaling services available, like Parse and Pusher, to name two.
Wobbals is correct, and In addition to what Wabbals has mentioned, generating sessions/tokens is very simple, the sample code required for each server language (PHP, NodeJS, C#, Ruby) is located in OpenTok's Github page.
Furthermore, if you choose not to have server side code and use Parse to handle your back-end, there is a wonderful writeup about how to use Parse's cloud code module for OpenTok to generate sessions and tokens.
Good Luck!
I strongly felt that the tokbox tutorial was quite basic but had steeper learning curve. So I ended up wrote out my own app-cum-tutorial.
Though late, I felt compelled to post here:
How To write your first iPhone Video Chat App using parse and opentok(tokbox)