As you can see, we use AWS as IaaS. Amongst various services offered by AWS, API Gateway was the essential service that saved us lots of time.Initially, we tried to use Lambda in conjunction with API Gateway since we thought it could save us more time by adopting a server-less backend, but soon found out that was not the case. A primary reason was that we were forced to deal with raw SQL queries when writing Lambda functions. There are many efforts made by the developers trying to use some sort of ORM within Lambda, but they are still premature. If you want to use Lambda and adopt server-less backend, maybe the best practice would be to use DynamoDB instead of RDS.
After evaluating API Gateway and the limitations around Lambda, we decided to develop our own REST APIs hosted by the web server running on EC2, and expose them through API Gateway. Because we used API Gateway, generating the client side API code was a piece of cake. We were able to instantly reflect the server-side changes onto the client-side code any time.
One feature we particularly liked about API Gateway is an ability to test each API in AWS Console without requiring any client code or the actual mobile app. Also, Stage variables were useful when switching from one stage to another. Usually, it ends up re-writing the config file on the client side, but in our case it was as simple as clicking on “Generate SDK” button in AWS Console and now the app points to the APIs deployed in different stage environment. Below is how we set up Stage Variable and Endpoint URL. The point is that ${stageVariables.url} will be replaced by the unique variable defined in each stage when you generate the client side SDK.
Maybe it’s worth noting that Stage can also point to your desktop PC where a local web server is running. We configured the ‘dev’ stage to point to the developer’s machine so that he could test the latest APIs using the actual mobile app without deploying any code on EC2. We found this was the most efficient way to develop the backend APIs while maintaining the integrity with the client side.
Apart from API Gateway and generated client side API code, we used Cognito to manage user identities and to provide secure access to the backend resources. At the time we started our development, User Pools wasn’t available so we went with Developer Authenticated Identities. Maybe we will switch to User Pools in the near future.
Since we adopted above framework, the time needed for each iteration was drastically shortened, and the app team was able to use the most up-to-date APIs in almost real-time without breaking the existing code. As a result, it only took us 8 weeks to develop the production quality backend APIs.
