In a previous blog post I said I would provide an overview of how I structure the Cloud Native Applications that I build. As always with software, there are a ton of different ways to do this. My approach is only my approach, you might find something here that helps you or you might be offended by the way I do things.
I build Cloud Native applications. That is, I develop applications that run in the Cloud and leverage Cloud services. This means I write application code and deploy Cloud infrastructure. I believe there are exactly 1,034,343 ways to deploy Cloud infrastructure. There is a wide range of tools available from a variety of vendors that want to help you deploy your Cloud infrastructure and get it connected to your application.
More often than not, these days, deploying Cloud infrastructure means writing Infrastructure-as-Code. If you are still doing anything in the console we can’t be friends. I recently became aware of Ampt and the new (to me) concept of Infrastructure-from-Code (IfC). I’m really struggling with how I feel about it and thought I should try to solidify my feelings in a blog post.
The thing I really want to talk about is abstraction. That is, each of the 1,034,343 solutions that help build Cloud infrastructure provide a layer of abstraction on top of foundational ways to build Cloud infrastructure. This layer of abstraction is often titled towards a particular use case to make it easier to build the infrastructure that satisfies the use case. Some solutions are focused on declarative infrastructure, some on support for multiple clouds and some on building applications in the Cloud.
I recently watched I tried 5 Firebase alternatives (from Fireship). I have thoughts on this same subject, but from a slightly different perspective.
I do Cloud Native Development and have built applications utilizing three of the BaaS solutions discussed in the video - Google Firebase, AWS Amplify and Supabase. With that said, today, I typically create applications directly in AWS and do not use any of the BaaS solutions. What follows are my thoughts on the three BaaS solutions I have used and a little about why I tend to stay away from them.
It has been a while since there were new posts here at FullsApps. The plan is to change that. I have been off working on a variety of projects and want to share some of the things I have learned. Let's start with this blog itself; which if you have been here before you will have noticed has been updated to something a little less embarrassing.
Since the release of multiple authorization support in Amplify GraphQL, a number of excellent blogs have been written about how multi-auth can readily support the public read, authenticated CRUD use case:
This post describes using multi-auth to support another use case: public create, authenticated read/update/delete.
To wrap up our series on the media-library project I want to reflect on the positive and negative parts of the project with a view to doing things better in the future, and then discuss what features might make sense for the next iteration.
It feels like this blog series has been going on forever, maybe because it has. We finally reached our goal of having something worth showing users in the last post. We can now turn our attention to getting the application published somewhere users can access it.
In this post we will finally get to the key part of the application - letting users select and download images.
In the last post we created a property list from which users can select a property. In this post we continue by creating the property components/pages.
We have done quite a lot of work to this point but we have yet to reach our most critical milestone - when we can turn over the application to a standard user to try the application and give us feedback. In this post we will finally start to add some GUI for the User (as opposed to the Admin, for whom we've added quite a bit of functionality).