Introduction​

I think a lot of people have come to realize there are some tremendous benefits to Cloud Native Development - scalability, availability, speed, etc. I'm not going to talk about that stuff in this post. Instead, I want to focus a bit on the key negative of Cloud Native Development and that is building an application that is tied to a Cloud vendor. I have always felt a little icky about it but in all of my cases the benefits have outweighed that negative, but I do recognize that I am typically only around for a part of a project. I'm likely not there when a team starts to think about re-homing or re-platforming their Cloud Native application.

As cloud adoption has started to slow I think Cloud users are starting to internalize the true cost of running in the cloud long-term. For some companies building applications in a way that makes them portable might have a real economic impact.

Sky Computing also provides another interesting angle on building applications that are cloud agnostic. The idea with Sky Computing is that you don't think about the platform you are running on and that there is something between the user and the cloud that makes the choice, typically based on cost. I don't that anyone is serious entertaining that idea for Cloud Native applications but it is an interesting idea.

The last thing that runs through my mind as relevant for this topic is what it means to really be Cloud Native. When I use the term I am thinking specifically about function based applications, not container based applications. You may think of container based applications as being both Cloud Native and portable, and I don't completely disagree. While I typically work from a function based approach I am interested in building application that are portable between these two scenarios. That is, if build an application that is backed by functions today I might want to move it to containers in the future.

With all that in mind you need to understand that I DO NOT build applications that are Cloud Native and portable. What I try to do is structure my applications in a way that they could be ported with some amount of, not overwhelming, effort. What follows are my thoughts on the way I structure the Cloud Native applications that I build.

Highlevel Overview​

Imagine a typical web or mobile application with auth, database, storage, etc. This is how I structure that application.

The result is two Cloud agnostic layers - UI and Business Services, and two Cloud specific layers API, Cloud Services/Repos.

UI​

For me, the most important abstraction lies between the frontend and the backend, or between the UI and the API. This provides total flexibility in how you build your UI, and how you rebuild your UI. For this reason, I try to stay away from the cloud specific client libraries whenever possible. In my experience the UI is the most commonly refactored part of an application, and it is the most likely part to have multiple active instances.

API​

I don't object to using either REST or GraphQL but the interface itself should never expose anything Cloud specific, but the technologies used to build the API are Cloud specific. These days I define everything related to the API using AWS CDK. I work almost exclusively with AWS and I talked about my preference for using CDK in a previous blog post. I can define the API interface itself, characteristics about the interface, permissions, authentication, link to handlers, and leverage ESBuild to bundle all of the downstream code behind the API all very simply and reliably with CDK.

One place in the application where there is some cloud specific code written is in the API handler itself. It needs to extract, and validate, relevant data from the API call, so that it can be passed to a Business Service. It is also sometimes where a specific API response is formatted.

I have toyed with the idea of what it would take to replace this layer if I had to move to another platform and it feels manageable. For example, if I wanted to move to containers I would likely swap out all of the API definition in CDK, and the API handlers to build effectively the same thing in software using a framework like Express.

Business Service​

Business Services are called by the API. The API handler accesses a Business Service via IoC (more on this below). This means the API handler doesn't know anything about a Business Service and visa versa. A Business Service is responsible for executing any required business rules. If it needs anything from a Cloud specific Service or Repo it will access it via an interface exposed by the service or repo. This interface also leverages IoC such that a Business Services know nothing about a Cloud specific Service or Repo. This follows a pretty common application paradigm where by a Business Service might talk to a Repository as the interface to a database.

One of the difficult considerations for any application is authorization. That is, limiting what a user can do in an application. There are cloud specific ways to expose this but my preference is to bake that into the Business Services layer.

Cloud Service / Repo​

A Cloud Service / Repo is the interface to a Cloud Service. For example, with AWS it might be Cognito, DynamoDB, S3, etc. A Cloud Service / Repo leverages Cloud specific SDKs to do what it needs to do. However, a Cloud Service / Repo still exposes a general interface via IoC. That is, a Cloud Service / Repo does not expose anything cloud specific. This makes it possible to change the underlying Cloud Service without changing what the Business Services knows about the underlying Cloud Service, which is nothing. This can include things like changing out a data source, for example moving from a NoSQL to SQL solution without the business logic side of the application knowing. In the event that the Cloud Service needs to be changed the cloud specific code would need to be rewritten but the rest of the application remains intact.

A Quick Note on IoC​

If you are not familiar with IoC it stands for Inversion of Control and it is all about the dependency inversion principal. This means we create interfaces as the dependency between components while the implementation details are defined and integrated separately. As a very simple example, it might mean a Registration Business Service is calling a Cloud Specific Service, like AWS Cognito, to create a user but all it knows it is leveraging a service with a function that requires username and password, the details are hidden and irrelevant. If the implementation details of how the user is created were changed the Registration Business Service would be none the wiser.

The one thing you have to get comfortable with when using IoC is that it does add more boilerplate to an application. It would be easier, and faster, to directly integrate your dependencies but you would lose some amount of portability which would result in more time and effort if you ever needed to move to another platform. If you are familiar with Redux but refused to adopt it because the additional boilerplate (no longer a thing given the Redux Toolkit) then IoC might not be for you.

The other benefit I have seen with IoC is more options for unit testing. For example, you can very easily isolate and unit test your Business Services without having to deal with dependencies.

My tool of choice these days for IoC is InversifyJS but there are a lot of different IoC tools out there. When I did my research (a couple years ago now) Inversify seemed to be the most popular and active (I don't know if that is still true). I have used it successfully on a number of projects at this point and really like it.

Wrap-up​

Hopefully, this quick summary makes sense. The underlying idea is to try to make the Cloud Native Application portable with a reasonable level of effort.

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.

The level of abstraction varies pretty widely across different solutions. Let’s get into it and I think (hope) you will see what I mean. And, keep in mind my background, and interest, is with tools that help build infrastructure for building applications, and I do that primarily on AWS.

Too Little Abstraction - CloudFormation​

In the AWS world CloudFormation is the OG when it comes to IaC. In fact, in AWS CloudFormation is really the base layer IaC, or you might think of it as no abstraction. That is, all of the other solutions we will discuss after this build their abstraction on top of CloudFormation.

The lack of abstraction with CloudFormation is why no one uses it, except for specific things they can’t do with the abstraction tool they have selected. That is, it gets used as a fallback when the abstraction tool doesn’t provide a desired capability. Generally, it just takes too much time and effort to cobble together and maintain CloudFormation. The abstraction tools exist for a reason. They make it easier and faster to build stuff on AWS.

What works:

• very easily understood (probably should be the foundation for anyone working on AWS)
• everything AWS (almost - custom resource escape hatch)

What doesn’t quite work:

• no abstractions
• too much work to get to the finish line

Too Much Abstraction - AWS Amplify​

First there was CloudFormation and almost immediately after someone said we can make this infrastructure deployment stuff way easier. Some other smart person, or maybe the same smart person, said if we figure out the use case we want to support we don’t have to support everything like CloudFormation does.

One of the solutions that came along, far from the first, was AWS Amplify, and I’m specifically talking about the Amplify CLI (Amplify has come to mean so many things). Amplify was created with the web and mobile application developer in mind. By running CLI commands you can define your application’s backend, things like APIs , databases, storage, etc. Each of these things maps to one or more AWS Services that is provisioned to build the related infrastructure that can then be used by the application being developed. In fact, the Amplify CLI builds CloudFormation that provides the desired infrastructure.

The challenge with using Amplify is the opposite challenge to using CloudFormation. Amplify provides a little too much abstraction. Sometimes it is hard to know what exactly will be provisioned, and maybe more critically, when things break it can be hard to fix them. It is important to remember that applications get deployed and operationalized.

This lack of direct relationship between Amplify and the provisioned infrastructure can also lead to users stepping past the invisible boundaries of the anticipated use case and pushing the limits on the amount of infrastructure being deployed; which comes at the cost of deployment time and maintainability.

What works:

• speed to solution is great

What doesn’t quite work:

• too much mystery, too hard to follow abstraction - hard to troubleshoot
• perception (maybe not reality) that the amount of abstraction makes it difficult to scale - too slow, too many things created, etc

Just Right Abstraction - Serverless Framework​

The Serverless Framework was one of the first IaC solutions I became aware of and I expect its long history has served it well. The solution has a large and loyal following because it works and I believe hits the sweet spot for the right amount of abstraction. When you use the Serverless Framework you know what is being deployed and, at the same time, you get real time savings over using CloudFormation.

The key thing that Serverless Framework really nailed was building an API. That is, they made it easy for the application developer to define and link all of the infrastructure needed to build the API that provides the frontend of the application access to the backend of the application. This involves tying together API Gateway and Lambda and the required underlying permissions. It has evolved into much more, including being able to easily adjust the myriad of settings available and inclusion of additional services.

Traditionally and largely still today, Serverless Framework leverages config files to define IaC. Most often this was yaml, sometimes json (depending on the team), and now includes support for different programming languages. However, even with this I would suggest it still feels like you are building config files, and you don’t really know if they are set up correctly until you run them to deploy your code.

What works:

• solved a really specific challenge - build a REST API - pull together the required bits
• evolved into allowing add-on of other required bits
• first IaC that really thought like a developer, not a sysadmin (probably a role/title that doesn’t exist anymore)

What doesn’t quite work:

• static files, not compiled
• additional of typed languages reliant on type definitions, not actual implementation
• linters don’t quite get there
• too easy to deploy stuff that doesn’t work as configured (coded)
• can use CloudFormation to get everything which is only okay
• granular permissions can get messy (requires add-ons)

Just Right'er Abstraction - CDK​

One of the well-known, and respected, influencers in the ‘serverless’ space is Alex Debrie, he literally wrote the book on how to use DynamoDB effectively. He has some history with Serverless Framework and recently penned this article on his blog - Why I (Still) Like the Serverless Framework over the CDK. Know two things, Alex is a much smarter guy than myself, and I couldn't disagree with someone more.

In my world, CDK (another solution from AWS) came along and really nailed some key improvements to Serverless Framework. There are two things that really sets CDK apart. One, CDK uses typed languages (I use Typescript) and you can build your IaC in a familiar coding paradigm. This comes with the benefits of type safety and intellisense; which means your IaC is much more likely to work when you deploy it. It also makes it easy to build your own abstractions. The second thing that CDK improves on is the ability to easily assign permissions.

The big miss with CDK is that it has felt like it has constantly been under construction for years. There was a first version that I would suggest didn’t do very well and then a second version that has done better. The challenge I have personally experienced several times are breaking changes. That is, you update to a new version and your solution no longer works as it did. This was so bad in version one of CDK that I gave up on it. It has surfaced again in version two but not as often. Although that is a negative, my willingness to continue to live with it should be seen as a testament to how much I like it versus the alternatives.

What works:

• different level of abstractions, but not giant leaps
• easily traced through cloudformation
• can still use cloudformation - when writing, when wanting to kill something
• everything in AWS

Improvements over Serverless:

• type safety - get configuration right prior to deployment
• intellisense - help with configuration while building the code
• real programming language - easy to create further abstractions (most useful for Functions where 95%+ config is the same for every function)
• simplified permissions

What could be better:

• new stuff is alpha for too long
• history of breaking changes

Too Early to Tell - Ampt​

Now, we have Ampt. It comes from the Serverless Framework team. The idea is you write your application code and it will figure out what infrastructure to deploy, hence, infrastructure-from-code (IfC). Currently, it supports AWS.

My initial reaction is that this is too much abstraction. That is, now I am completely separated from the infrastructure I (and others) will have to support when our application moves into production. I do expect that this will reduce the time to build an application but that just isn’t the whole picture. I’m going to need to troubleshoot things when they go wrong. I’m going to need to reconfigure things. I may have to migrate the application to another platform. These things feel like they will be harder.

What looks good:

• at the end of the day I’m just trying to create an application, this makes sense

Where I have questions:

• is it just lambda/serverless
• what about containers

Keys to the Right Level of Abstraction​

These are my thoughts on how I access the level of abstraction provided by an IaC/IfC solution.

• I can easily follow how the abstraction works - for troubleshooting and to understand what has been deployed. I feel like the operational side of the application sometimes gets overlooked. When we build an application we need to remember that the application needs to be secured, it needs to be backed up, it needs to be maintained, etc. Probably, the critical question is - what do you do when things stop working?
• The abstraction saves time and reduces errors. That is, the abstraction helps get the right things deployed, and correctly links them (securely).
• I can keep my application from getting intertwined with the abstraction. That is, I can still fool myself into thinking I have a ‘somewhat’ portable application and I can undo and redo the abstraction as needed to support another platform. Lots of teams seem willing to look past this but that feels very dangerous to me.

Conclusion​

I’m going to try to keep an eye on Ampt and not be too judgy but that is tough for me. For now, I continue marching forward with CDK.

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.

Disclaimer - it has been a little while since I spent a lot of time with Google Firebase and AWS Amplify so some of my take may be a little out of date.

My Main Issues with BaaS Solutions​

Solution Lock In / Tight Coupling / Lack of Flexibility / Lack of Portability​

If there is one main reason I stay away from the BaaS solutions it is to avoid solution lock in. None of the BaaS providers do a particularly good job of letting you build an application that doesn’t completely rely on their solution.

When I build an application I try to decouple as much of it as I can from the platform it runs on. This is one of the changes of Cloud Native Development. Achieving a level of decoupling leaves me options in the future for where the application is deployed.

The BaaS solutions typically start with encouraging (pushing, requiring) you to use their client library to interact with their backend services. In some cases you have options, I will discuss this more with the individual solutions, but the options are limited. This means you cannot easily decouple your solution from their platform and it also makes it more difficult to decouple your frontend and backend.

Another area where you can get locked in is around authentication and authorization. In particular, the way you manage user permissions tends to be proprietary to the BaaS solution and is not easily portable down the road.

I do most of my Cloud Native Development on AWS today. You might be thinking that I’m locking myself into AWS as a vendor, why is that different from the BaaS solution?. The answer to that is a bit complicated but with AWS I’m defining the services I use and how I use them which allows me flexibility in how I construct an application. This provides a bit more flexibility. However, make no mistake, that applications I create on AWS are not runnable anywhere else but I can, and do, create reasonable abstractions that make it possible to move from one platform to another with some effort.

Let me illustrate some of this with two real world examples.

The first example is a hotel digital media library application that I built on Firebase. The application was the subject of a series of blog posts on this site several years ago. I recently started thinking about porting the solution to AWS. Every single part of the solution would need to be updated. In the frontend I would need to change the libraries that are used to access backend services. This would probably lead to deeper changes based on new responses from the new backend. The backend services would obviously change and I would need to port all of the associated data. User permissions are specific to Google Firestore and would need to change. The things that might survive are some amount of the UI and some of the function code that was written to process images. This is the level of wholesale change I try to prevent when I build Cloud Native applications today.

The second example is a recent application that started on Supabase and moved to AWS. One of the parts of Supabase I like is that you can call (most of) your database and authentication via a REST API Supabase exposes; which is how I integrated the backend and frontend in the application. When I decided to port the application to AWS I rewrote the backend and I only had to make minor changes to how I was using the API; changing the API URL and to how some of the requests were constructed (the Supabase REST API is a little quirky, more on this below). I was even able to continue using the models I had defined for the API because I exposed the same data from AWS. In this case, the database changed from SQL (Supabase Postgres) to NoSQL (AWS DynamoDB) without the frontend application being any the wiser. It only took a couple days to port the whole thing and I had a high degree of confidence the application was still working. This is the type of thing I do more of today to future proof the Cloud Native applications I build today.

It is worth noting that locking in on one solution is not totally bad, it can have a benefit. If you are not interested in having more options for deploying your solution elsewhere and you lock in to one solution you can typically build a smaller, simpler solution that may end up being easier to support. The hotel media library I referenced in the example above has continued to work in Firebase without issue for several years.

Multiple Environments / Infrastructure-as-Code​

The other big thing that has changed for me over time is more and better use of Infrastructure-as-Code (IaC). This is never a top tier feature or discussion point for BaaS solutions. When you get started defining your backend services it is tempting to use the console to get exactly what you need as quickly as possible (the BaaS solutions don’t discourage this). However, you will quickly run into a challenge. It is difficult (impossible) to create another exact copy of your environment. You need easily duplicated environments for two very important reasons. One, you can give each developer their own environment so they don’t run into one another. Two, you can deploy a production environment while working on new features in another environment.

This probably sounds a bit rudimentary to most folks at this point but then why don’t the BaaS solutions take this a bit more seriously? This was an ongoing challenge with AWS Amplify for a long time (might be better now). Supabase mentions this in an article that discusses you building smart deployment scripts to support this. I have seen references to this in the Google Firebase docs but I also remember doing a bunch of manual duplication in the past (again, this may not be the case anymore).

Having the ability to create isolated environments in or across multiple AWS accounts is a foundational part of how I build applications today and I intentionally choose tools that make this easy.

Thoughts on Specific BaaS Solutions​

Google Firebase​

As discussed above, I have built one application on Firebase (media library) that also leverages some bits from Google Cloud. I have considered it for other projects but ultimately have ended up staying away. Most of my work is web applications. If I did more mobile development I might feel differently about Firebase. I do think it is particularly strong for mobile development.

My general impression is that Google Firebase is a solid solution. I don’t think there is any doubt that it is the dominant player in the BaaS solutions space. It is interesting that it started as an acquisition by Google as opposed to being something spun out of Google Cloud. Over time I believe Firebase has grown closer to Google Cloud but has largely existed separately. This differs quite a bit from how AWS Amplify and Supabase have come to be (more on that follows).

One of the things I really like about this relationship between Google Cloud and Firebase is how Firebase exposes simplified services, while leaving you the option to step up to Google Cloud services when required. I think this was likely an intentional strategy from Google. The best example of where this shines is Authentication. Firebase Authentication is quite straightforward. If you compare this to AWS Amplify where they expose AWS Cognito it couldn’t be more different. Cognito has so many options and can be quite overwhelming when you are trying to wrap your head around how to use it in an application.

The ability to leverage Google Cloud services in Firebase also lets an application grow when and where needed. For example, in the media library application I leverage Vision AI to pull more information from images in the library. This breadth of service is something that a small vendor like Supabase cannot compete with.

The miss with Firebase for me is the lack of tools to help separate the frontend and backend via API. There may be ways to use Functions to achieve this but it doesn’t seem like something that Firebase promotes or recommends.

Likes:

• Rock solid
• Good lineup of supported services - really good for mobile
• Simplified solutions
• Ability to incorporate Google Cloud services

Dislikes:

• No real API solution for better flexibility / portability

AWS Amplify​

In the past I have had a particular interest in AWS Amplify. To that end I was a co-founder of the AWS Amplify Meetup in Toronto - pre-pandemic. Even with that, I have only used Amplify on two production grade projects. I have used it a few more times for prototyping or proof of concepts. I generally and intentionally choose not to use Amplify when building applications on AWS today.

AWS Amplify is an interesting solution. It does seem that it came about as AWS’s attempt to compete with Google Firebase but it does things differently. As opposed to building specific solutions for developers building applications, AWS Amplify, attempts to provision full AWS services in a simplified way that makes them more easily used by application developers. When this works, it works okay, when it doesn’t work it makes for an environment that can be tricky to troubleshoot. Sometimes it feels like there is a bit too much mystery in what Amplify is doing under the covers. One of the side-effects (benefits?) of Amplify implementing AWS services directly means you are going to get to know the underlying AWS services (even if you don’t want to).

I would speculate that Amplify’s attempt to catch a leading rival has come with some growing pains. Amplify has a bit of a history of introducing breaking changes from build to build. That is, when you upgrade Amplify and deploy your solution you may find things that no longer work.

Amplify also comes with some ‘interesting’ solution choices - like implementing a GraphQL API on top of AWS DynamoDB. For those who don’t know DynamoDB, it is a NoSQL database that exposes two keys that can be used for queries. If you don’t know GraphQL, it is the API that allows queries to be coded into API requests. That has always felt like an odd combination to me. It leads to a solution that ends up doing a lot of table scans and filtering

Also, the Amplify codegen creates a new DynamoDB table for each GraphQL schema which can lead to a lot of DynamoDB tables. This feels like another strange choice when another part of AWS preaches and extols the virtue of single-table design with DynamoDB. On one project I worked on we hit the DynamoDB table limit for a Region in an AWS Account - it is a quick ticket with support to adjust this but probably shouldn’t happen.

Historically, Amplify has been a bit rough to use in team environments. They have attempted to improve this over time.

One of the things I really like about Amplify is that they leverage APIs to separate the frontend and backend (GraphQL and/or REST). However, this has some challenges. First, you define your backend by running CLI commands in the frontend - this creates some weird coupling. Also, you are encouraged (pushed) to use the AWS Amplify client as your library to use the APIs that get created. This also creates a weird coupling, and it isn’t actually necessary - you can use other API clients if you prefer.

I feel like I have beat up Amplify a little bit here - that wasn’t intentional. It is a really great solution for getting an application running as quickly as possible. Also, through the Meetup in Toronto, we met and had a couple AWS team members come and speak and they are solid, super smart folks.

Likes:

• Fast to prototype solutions
• Use of production quality AWS services
• Decent learning path to learn more about specific AWS services
• API separation of frontend and backend

Dislikes:

• Sometimes hard to follow or modify how AWS services are deployed and configured
• Implements anti-patterns
• History of being brittle - breaking changes
• Hard to use in a team environment - too many objects, too slow

Supabase​

Supabase is a YCombinator startup that has received a tremendous amount of early funding. For some reason Supabase likes to market itself as being ‘open source’. I don’t really get why it would be important that a service is running on an open source platform, unless this the story is about portability and I don’t think it is - I’m just looking for the service.

The thing that is really great about Supabase is that it provides easy access to create SQL databases. This is not super easy, or even possible, with Firebase or Amplify (Amplify does offer some level of support with Aurora - the last/first time I tried it, it wasn’t great). They both opt for NoSQL databases by default.

The other thing I like about Supabase is that they do expose a lot of what they offer via a prebuilt REST API which offers some portability (I discussed this above). Some of the REST calls look a little weird but the responses are good, it is just the way you construct requests that can be a little weird. Also, it is probably worth noting that you don’t have a lot of flexibility with this prebuilt API. If you want more elaborate requests than what is presented you are probably going to have to do something with Stored Procedures or Functions.

Probably the biggest hurdle for Supabase is the lack of services. They provide many of the basic services but lack the breadth of portfolio from Google or AWS. I am a bit surprised that Supabase has stayed away from providing somewhere to host a web application. So, if you go with Supabase you will be looking for another provider (maybe someone like Netlify or Vercel) to host the frontend of your web application.

One of things that is interesting about Supabase is that it runs on AWS. So, don’t choose Supabase because you want to avoid AWS (side note, I think there is a lot more Cloud on Cloud out there than people realize).

Likes:

• SQL
• A decent amount of REST support

Dislikes:

• Cannot easily create different environments
• No hosting for the application itself (limited services in general)
• The REST API is okay but I would consider it a little non-standard and not flexible

BaaS Solution Conclusions​

Firebase, in particular, feels like a perfectly reasonable production application solution if there is no compelling reason to think about portability.

I might occasionally use Amplify or Supabase for some quick prototyping but even that is tough to justify. It doesn’t save me very much time on the prototype and it costs me time as soon as the prototype moves forward to anything like a proof of concept.

Supabase might have a home in my toolkit for when I need a quick SQL database (and that need does come up from time to time) for something non-production.

If you want to see more about how I build Cloud Native Applications stay tuned, I will be posting more on that soon.

Background​

When I originally created FullsApps (I think something like 5 years ago) I did a little bit of research into where I could create a blog. I looked at a bunch of different options. For some reason I just couldn't find a solution that looked like what I was after. I landed on Google Blogger (formerly Blog Spot I think) for no other reason than I had used it before. It provides a decent user experience for the blog creator. You have some customization options and you have some control over what the site looks like. It also integrates pretty well with Google Analytics to understand how the blog is being used. It also integrates with Google Ads but that creates a pretty terrible user experience (which past users can confirm).

Two things became an issue with using Blogger.

1. I ended up having to write posts in html to create something that looked close to reasonable (and most would say it still looked awful). In particular the ability to create code snippets and diagrams was really bad. The ability to add images was also painful.
2. The Lighthouse score with Blogger, and the performance in general, was terrible.

Not really an issue, but it did bother me that as a developers I didn't have a hand in the actual technology used to create the blog.

Solution​

In my work as a consultant, depending on the stage I join a project, I often need a solution for documentation. Someplace to for diagrams, API docs and general solution discussion. I often use solutions like Confluence or Sharepoint if the team I'm working with uses them currently. However, sometimes the team I am working with doesn't have a solution in place. One group I worked with was fond of using Sphinx (a Python based documentation solution) in those situations but where my primary programing language is Typescript (sometimes Javascript) and my primary front-end framework is React I thought something a bit more aligned with my tech stack might make sense.

After some research I became aware of Docusaurus. It is a popular solution from the Facebook Open Source team and is used for the React docs. If you have read anything else in this blog you likely know how I feel about the open source projects from Facebook - I am a fan. I almost exclusively use React for front-ends (I have done a tiny bit of work in Vue and raw Javascript but don't prefer either). Also, I have done quite a bit of work with GraphQL.

With that I started using Docusaurus as my go to solution for project documents. The ability to write in markdown and the ability to integrate with Mermaid for diagrams and plugins for both GraphQL and OpenAPI where key features. Also, the ability to logically layout and navigate the docs I created was perfect. The one feature I didn't really use was the ability to create a blog.

At some point, I had some free time and explored the ability to create a blog in Docusaurus and I was sold.

Requirements​

When I think about the things I care about in a blog today, these are the things that come to mind:

• Ease of creating content
• Ability to track activity (so I can understand what content is useful)
• A good Lighthouse score (for SEO - so the content can be found)
• Ability to customize, perhaps grow into a proper website

This led to what you see today.

Docusaurus​

The user/developer experience with Docusaurus is excellent. It is a reasonable mix of out-of-the-box functionality and developer control. There is a tiny bit of config to create a blog specific Docusaurus project. The Docusaurus docs are excellent and cover everything you need to know.

Blog posts are written in Markdown in the projects repo (following some guidance from the Docusaurus docs on specific Markdown formatting). Markdown files are created with a specific name and placed in a specific directory. They can be approved like a typical Pull Request (for easy review and editing). I author posts in VS Code with help from extensions: Code Spell Checker and markdownlint.

With Docusaurus the Lighthouse score is excellent. The Desktop score is very close to perfect. There a handful of issue with links that could be resolved to bump it higher. The Mobile score has some performance issues - I believe due to sub-optimal images (something I may try to address in the future).

I am using the Google GTag Plugin provided by Docusaurus. This provides me some usage data in Google Analytics. It is dead simple to setup and seems to work as expected.

Netlify​

When working on consulting projects all of my Docusaurus deployments were to AWS (following static site hosting practices using S3 and CloudFront). I could have used AWS to host this blog but I wanted to try out another solution, particularly so I can grow into possibly using something other than Docusaurus in the future, so I chose to use Netlify.

My experience with Netlify has been extremely positive so far. If you haven't used it I would encourage anyone to take a look. You point Netlify to your Git repo (in my case GitHub) and it will automatically deploy a preview of your site (for both web and mobile) when you create a Pull Request on an identified branch. When the Pull Request is approved Netlify automatically deploys to Production.

The only other things I did were to update my domain to use the Netlify DNS and to create an environment variable for my Google Analytics Tag.

The usage tier I'm currently using is 100% free, no credit card required.

Future​

I really like Docusaurus and it provides a lot of great features for zero effort. However, the one thing I'm still missing is maximum flexibility. At some point I may move to a Remix, possibly NextJS, solution - I have been trialing both. This would allow FullsApps to grow into a complete website where I have total control.

• AWS Amplify Multi-Auth GraphQL — Public Read and Authenticated Create, Update, Delete.
• Multiple Authentication Types in AWS Amplify.

This post describes using multi-auth to support another use case: public create, authenticated read/update/delete.

• Public ("unauthenticated") users can create objects in a GraphQL table; i.e., a user can create an object in the table without having to sign in with user name and password.
• The unauthenticated user cannot read, update, or delete any object in the table.
• An authenticated user can read, update, delete the objects that s/he owns in the same GraphQL table after signing into Amazon Cognito with user name and password.

An example of this use case is where a website has a public form that asks users to fill out (e.g., taking a survey) without having to sign in. The information from the form is stored in the GraphQL table. Other than creating the form data in the table, unauthenticated users cannot read, update, or delete the data in the table. On the other hand, the owner of the form is the authenticated user who can collect and process the information stored in the table after signing in with user name and password.

To show this use case, we will walk through building an example React app which we will call "publiccreate".

The app will have a simple form allowing anyone to enter a name to sign up, after which the names are stored in a GraphQL table:

To show that the pubic user cannot read the names in the table, the user will get an error when the "List Signups" button is selected.

When the "Log in as Admin" button is selected, the Amplify authentication log in screen is presented to the user:

After logging in as Admin, the Admin can see the names that have been entered, and can also delete any names from the table:

To support this use case, the following authorization types are used in this example app:

• AWS IAM type for the unauthenticated public user
• Amazon Cognito User Pool for the authenticated user called "Admin"

We will walk through the following steps to create this example app:

• Create React App
• Initialize Amplify project
• Configuring multi-auth in GraphQL
• Enabling unauthenticated access
• Defining the schema with multi-auth rules and ownership
• Deploying the backend to the cloud
• Creating "Admin" user in Cognito User Pool
• Developing & testing the app

Getting Started​

Setting up React, Amplify

Create React App​

First, we create the React app:

npx create-react-app publiccreate

Amplify Init​

We now initialize the Amplify project:

cd publiccreate
amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project publiccreate
? Enter a name for the environment dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm.cmd run-script build
? Start Command: npm.cmd run-script start
Using default provider  awscloudformation

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use default
Adding backend environment dev to AWS Amplify Console app: d1rzx3mroddkau
| Initializing project in the cloud...

Configuring Multi-Auth in GraphQL API​

The next step is to add the GraphQL API with multi-auth support by running amplify add api.

As highlighted below:

• The Amazon Cognito User Pool will be the default authorization type and will be used for the "Admin" user.
• You have to choose "configure advanced settings for the GraphQL API" in order to configure the additional AWS IAM auth type which will be used for public users.

amplify add api
? Please select from one of the below mentioned services: GraphQL
? Provide API name: publiccreate
? Choose the default authorization type for the API **Amazon Cognito User**
**Pool**
Using service: Cognito, provided by: awscloudformation

The current configured provider is Amazon Cognito.

Do you want to use the default authentication and security configuration?
Default configuration
Warning: you will not be able to edit these selections.

How do you want users to be able to sign in? Username
Do you want to configure advanced settings? No, I am done.
Successfully added auth resource
? Do you want to configure advanced settings for the GraphQL API **Yes, I**
**want to make some additional changes.**
? Configure additional auth types? **Yes**
? Choose the additional authorization types you want to configure for the API **IAM**
? Configure conflict detection? No
? Do you have an annotated GraphQL schema? No
? Do you want a guided schema creation? Yes
? What best describes your project: Single object with fields (e.g., “Todo”
with ID, name, description)
? Do you want to edit the schema now? Yes

At this point, you are ready to define the schema to support this use case.

Defining The Schema​

The file that you are editing is (relative to the project's root directory) amplify/backend/api/publiccreate/schema.graphql. Replace the contents with the following:

type Signup
  @model
  @auth(
    rules: [
      { allow: owner }
      { allow: public, provider: iam, operations: [create] }
    ]
  ) {
  id: ID!
  name: String
  owner: String
}

"Signup" is a simple table where "name" will store the name that the public user will enter on the form. The critical configurations are the auth rules and the "owner" field:

• allow: owner specifies that the owner of the table can perform the default operations, namely create, read, update, delete. By default, the authorization provider is AWS Cognito User Pools. In our example, the owner will be the Cognito user "Admin" which we will create in the following steps below.
• allow: public, provider: iam, operations: [create] specifies that a public user can use the AWS IAM authorization provider to create objects in the table but is not allowed to perform any other operation on the objects.
• owner: String specifies the Cognito user name who will own the object in the table which in our case will be the "Admin" user name. As you will see later in the code, after the unauthenticated user enters a name, the code will add an object into the Signup table consisting of the name that the user provided, and owner set to be "Admin". This makes "Admin" the owner for the object that the unauthenticated user is creating. Because the object's ownership is "Admin", unauthenticated users no longer have the authority to read, update, or delete the object (even though the unauthenticated user created the object). Please refer here for the full background on ownership authorizations.

Enabling Unauthenticated Access​

To enable unauthenticated access, we have to update the Amplify auth category by running amplify auth update, and walk through all the auth configuration as highlighted below:

amplify auth update
Please note that certain attributes may not be overwritten if you choose to
use defaults settings.

You have configured resources that might depend on this Cognito resource.
Updating this Cognito resource could have unintended side effects.
Using service: Cognito, provided by: awscloudformation
What do you want to do? **Walkthrough all the auth configurations**
Select the authentication/authorization services that you want to use:
**User Sign-Up, Sign-In, connected with AWS IAM controls (Enables per-user**
**Storage features for images or other content, Analytics, and more)**

Allow unauthenticated logins? (Provides scoped down permissions that you can
control via AWS IAM) **Yes**
Do you want to enable 3rd party authentication providers in your identity pool?
No
Do you want to add User Pool Groups? No
Do you want to add an admin queries API? No
Multifactor authentication (MFA) user login options: OFF
Email based user registration/forgot password: Enabled (Requires per-user email
entry at registration)
Please specify an email verification subject: Your verification code
Please specify an email verification message: Your verification code is ####

Do you want to override the default password policy for this User Pool? No
Specify the app's refresh token expiration period (in days): 30
Do you want to specify the user attributes this app can read and write? No
Do you want to enable any of the following capabilities?
Do you want to use an OAuth flow? No
? Do you want to configure Lambda Triggers for Cognito? No
Successfully updated resource publiccreate2811e9a5 locally

Some next steps:
"amplify push" will build all your local backend resources and provision it in
the cloud
"amplify publish" will build all your local backend and frontend resources (if
you have hosting category added) and provision it in the cloud

Deploying The Backend​

At this point, we have the Amplify api and auth categories configured locally which you can verify by running amplify status.

amplify status

Current Environment: dev

| Category | Resource name        | Operation | Provider plugin   |
| -------- | -------------------- | --------- | ----------------- |
| Auth     | publiccreate2811e9a5 | Create    | awscloudformation |
| Api      | publiccreate         | Create    | awscloudformation |

We are now ready to amplify push the backend to the cloud.

PS C:\Users\pangj\publiccreate> amplify push
√ Successfully pulled backend environment dev from the cloud.

Current Environment: dev

| Category | Resource name        | Operation | Provider plugin   |
| -------- | -------------------- | --------- | ----------------- |
| Auth     | publiccreate2811e9a5 | Create    | awscloudformation |
| Api      | publiccreate         | Create    | awscloudformation |

? Are you sure you want to continue? Yes

GraphQL schema compiled successfully.

Edit your schema at ...\schema.graphql or place .graphql files in a directory
at \publiccreate\schema
? Do you want to generate code for your newly created GraphQL API Yes

? Choose the code generation language target javascript
? Enter the file name pattern of graphql queries, mutations and subscriptions
src\graphql\*\*\*.js
? Do you want to generate/update all possible GraphQL operations - queries,
mutations and subscriptions Yes
? Enter maximum statement depth [increase from default if your schema is deeply
nested] 2

Updating resources in the cloud. This may take a few minutes...

Creating "Admin" User​

Before we go to our React app, we need to create the Admin user in Cognito. Log into the AWS console, go to Cognito, and choose "Manage User Pools" as shown here:

After selecting the publiccreate user pool in the next screen, you will land on the following page where you should choose "Users and groups" and "Create User".

After selecting "Create User", enter "Admin" and any temporary password that you like as shown in the following popup, and hit "Create user":

At this point, the Admin user has been created. After we create the app below, the Admin user will be asked to change the password after signing in for the first time.

The Example Signup App​

We will develop the app in two parts:

• A simple form for a public user to enter names and stored in the Signup table that we've created in the backend. We will verify that the names are stored in the Signup table by going to the DynamoDB console. We will also create code to read the names in the Signup table and verify that public users cannot read from the Signup table.
• We will add a login page for the Admin user to sign in, and verify that Admin can read and delete objects in the Signup table. We will verify that after logging out, the Signup table objects cannot be read anymore.

First, run npm install aws-amplify @aws-amplify/ui-react from the project's root directory to install the Amplify components to be used by the app.

npm install aws-amplify @aws-amplify/ui-react

Public Create​

Edit src/App.js (relative to the project's root directory), and replace the contents with the following.

import React, { useState } from 'react';
import Amplify, { API, graphqlOperation, Auth } from 'aws-amplify';
import { withAuthenticator } from '@aws-amplify/ui-react'; // To be used for Admin login
import '@aws-amplify/ui/dist/style.css'; // Needed to provide styling for Admin login
import { createSignup, deleteSignup } from './graphql/mutations';
import { listSignups } from './graphql/queries';
import awsconfig from './aws-exports';

Amplify.configure(awsconfig);

async function addSignup(event) {
  event.preventDefault();

  const data = new FormData(event.target);
  const name = data.get('name');

  if (name === '') {
    return;
  }

  try {
    await API.graphql({
      // Cannot use graphqlOperation() here
      query: createSignup,
      operationName: 'createSignup',
      variables: {
        input: {
          name: name,
          owner: 'Admin', // Owner is set to Admin
        },
      },
      authMode: 'AWS_IAM', // Create as unauthenticated IAM user
    });
  } catch (err) {
    alert('Failed to create signup ' + err);
  }

  alert('Added ' + name);
  document.getElementById('getname').value = '';
}

function ShowSignups() {
  const [signupList, setSignupList] = useState([]);

  const getSignups = async () => {
    let list;
    try {
      list = await API.graphql(graphqlOperation(listSignups));
    } catch (err) {
      alert('List Signups Error: ' + err);
      setSignupList([]);
      return;
    }

    setSignupList(list.data.listSignups.items);
  };

  return (
    <>
      <button onClick={getSignups}>List Signups</button>
      <table>
        {signupList.map((user) => (
          <tr>
            <td>{user.name}</td>
          </tr>
        ))}
      </table>
    </>
  );
}

function App() {
  return (
    <>
      <form onSubmit={addSignup}>
        <input id='getname' type='text' name='name' placeholder='Enter name' />
        <input type='submit' value='Sign up' />
      </form>
      <ShowSignups />
    </>
  );
}

export default App;

App() creates a simple form allowing anyone to enter a name. When a name is submitted, addSignup() is called to create a Signup object using GraphQL:

await API.graphql({
  // Cannot use graphqlOperation() here
  query: createSignup,
  operationName: 'createSignup',
  variables: {
    input: {
      name: name,
      owner: 'Admin', // Owner is set to Admin
    },
  },
  authMode: 'AWS_IAM', // Create as unauthenticated IAM user
});

Note the following:

• AWS_IAM is set as the auth type
• graphqlOperation() cannot be used to pass the operation to API.graphql() because it doesn't expose the authMode parameter
• 'Admin' is set in the owner field

ShowSignups() calls API.graphql() to get the names from the Signup table. API.graphql() will return an error if it is unable get the names from the Signup table.

Now save App.js and run npm start from the project's root directory.

Enter a name and hit "Sign up".

Then click "List Signups" and you will get the following error message (from the graphQL call) as expected since you are a public user:

To verify that the names have been created in the Signup table, log into the AWS console, and go to DynamoDB to search for the Signup table and see the contents of the table:

Note that the names have been added, and owner for each item is Admin.

Admin Read, Delete​

The remaining work is to add code to support logging in as an Admin, and be able to read and delete the names that have been entered by public users.

Update App() to the following:

function App() {
  const [loginAsAdmin, setLoginAsAdmin] = useState(false);

  const handleLogout = async () => {
    try {
      await Auth.signOut();
    } catch (err) {
      alert('Unable to log out: ' + err);
    }

    setLoginAsAdmin(false);
  };

  const LoginAdmin = () => {
    return (
      <>
        <ShowSignups />
        <button onClick={handleLogout}>Logout</button>
      </>
    );
  };

  if (loginAsAdmin) {
    const AdminScreen = withAuthenticator(LoginAdmin); // Amplify auth login screen
    return <AdminScreen />;
  }

  return (
    <>
      <form onSubmit={addSignup}>
        <input id='getname' type='text' name='name' placeholder='Enter name' />
        <input type='submit' value='Sign up' />
      </form>
      <ShowSignups />
      <button onClick={() => setLoginAsAdmin(true)}>Log in as Admin</button>
    </>
  );
}

We are leveraging the Amplify Higher Order Component withAuthenticator() to show the Amplify login screen.

The ShowSignups component is reused by the new code in LoginAdmin() to get the names in the Signup table. Update ShowSignups to the following code to allow the Admin to delete objects from the Signup table.

function ShowSignups() {
  const [signupList, setSignupList] = useState([]);

  const getSignups = async () => {
    let list;
    try {
      list = await API.graphql(graphqlOperation(listSignups));
    } catch (err) {
      alert('List Signups Error: ' + err);
      setSignupList([]);
      return;
    }

    setSignupList(list.data.listSignups.items);
  };

  const removeSignup = async (id) => {
    try {
      await API.graphql(graphqlOperation(deleteSignup, { input: { id: id } }));
    } catch (err) {
      alert('Failed to delete ' + err);
    }

    getSignups();
  };

  return (
    <>
      <button onClick={getSignups}>List Signups</button>
      <table>
        {signupList.map((user) => (
          <tr>
            <td>{user.name}</td>
            <td>
              <button onClick={() => removeSignup(user.id)}>Delete</button>
            </td>
          </tr>
        ))}
      </table>
    </>
  );
}

Now run the app. Click the "Log in as Admin" button", and it will take you to the Amplify auth login screen. Log in as Admin with the password that you had set when you created the Admin user above.

The first time you log in as "Admin", you will be asked to change the password. You will also be asked to verify contact information in which case you can just specify "skip" for now.

Now when you click "List Signups", you should see the names that have been entered.

Furthermore, you can delete any name, and the list will refresh. You can also go back to DynamoDB in the AWS Console as above to verify the contents of the table.

Click "Logout", and you will be taken back to the public user page where you will get an error again if you click "List Signups".

Summary​

We have walked through creating a React app using Amplify multi-auth to support the public create, authenticated read/update/delete use case. The key considerations to supporting this use case are:

• Choose "configure advanced settings for the GraphQL API" when you run amplify add api in order to specify the additional AWS IAM auth type
• Choose "Walkthrough all the auth configurations" when you run amplify update auth in order to allow unauthenticated logins
• Defining the schema with the auth rules { allow: owner }{ allow: public, provider: iam, operations: [create] } and explicit definition of the "owner" field
• Calling API.graphql() without graphQLOperation() to create an object so that authMode can be set to "AWS_IAM", and to assign the owner field to an authenticated user

Positive​

• Hooks - This entire application is written without using a single React Class Component. To say I am a fan of Hooks is an understatement. By not using Hooks I find my code is both easier to write and read.
• Render props - I am a fan of the render props pattern, although it does seem that custom Hooks may replace render props over time. I am not a fan of Higher Order Components (HOC). This entire application is written without creating a single HOC (but we do use a few).
• Firebase (the platform) - I really like Firebase as a platform. I don't remember having a problem with it throughout the entire development cycle. I appreciate the efforts to keep Firebase minimal and not bloat it with a bunch of rarely used features. In particular, Firestore and Functions are solid and much easier to use than the solutions provided by others.
• Semantic UI - I had some consternation about choosing Semantic UI React as the UI framework for this project. I was slightly worried it had a dated look and feel. However, I feel more than ever that it was the right chose. It is easy to use and it has tons of options to do almost everything you need.

Negative​

• Separation of back-end and front-end - Firebase could do more to help developers by drawing some separate between the back-end from the front-end of an application. Other platforms have embraced the concept of an API layer instead of making calls to the back-end directly. This separation provides the developer more options for how to run/deploy their application in the future. Firebase may see this as a bit of a risk but I expect not having this may end up being a bigger risk. With all that said, the ball is in the court of the developer to provide separation. In Media Library we did an okay job of this. I would explore other options for providing more meaningful separation.
• Separation of components and containers - There has been some discussion about this on Twitter and I have to say that I am lining up behind those who are in favor of not creating a separation between components and containers. I am still in favor of creating both "view" components and "container" components but I don't think there is much advantage to placing them in separate folder structures.
• Type safety - At the beginning of this project I made some statements about not wanting to be slowed down by using Typescript. Although I stand by those statements there are some places in this application that would benefit from type safety. To that end, we did add PropTypes to the application; something I said we wouldn't do at the start. The application is still small enough that this hasn't been a major source of problems but I expect the use of Typescript from the start would pay long-term benefits with regard to maintaining this project.

Other​

• Redux - I really like Redux but I recognize the reason it receives criticism. There is a tremendous amount of boilerplate required to use Redux. However, the developer tools continue to be a valuable tool in my toolkit. Also, I feel like my Redux testing strategy provides a high level of confidence in my use of state. It does seem that the React developer community is trending away from using Redux. There are other solutions like MobX that are popular. There is also the option of using useContext directly. At the start of this project I made the intentional choice to not use useContext primarily because I like Redux and I think the boilerplate overhead is more than overcome with the supportability offered by Redux. However, one never wants to be an island in the developer community, that is what leads to code that no one wants to work on or maintain. So, it seems that I must evolve. I expect leveraging local cache options that use useContext, like the Apollo Client, will be what I embrace going forward (I will miss you Redux).
• Testing - My view of testing React projects changed dramatically from the start to the end of this project. If you have been following along you know that I started by thinking I would use Enzyme and I ended up using React Testing Library (with Jest as a constant). In addition to choosing a different testing framework I also solidified my personal testing strategy. I now "categorize" my components and test them according to the type of tests that will provide the appropriate coverage for the "category".

What's Next​

This is a laundry list (and only a partial list) of features that might make sense in the next iteration of this application.

• Support for multiple languages.
• User administration.
• Approval workflow in the registration process.
• Support for other types of media - videos, 360s, documents.
• Support for a large number of properties (100s or 1000s).
• Global image search.
• Ability to more easily adjust branding.
• More testing.
• Remove an image from a property - currently you can only delete the image
  • When an image is added we add the property to the image but we do not do the reverse, that is, we don't add the image to the property so we need to lookup property images whenever we need them (this might make the system more efficient)
• We have hard-coded the reproductions we want generated when an image is uploaded. This would be a good candidate to be stored in the database and be configurable in the admin GUI.
• We are using ImageMagick to reproduce images. I believe Stream & Sharp hold some promise for faster processing (http://sharp.dimens.io/en/stable/api-resize/).
• Our caching is quite unsophisticated. Right now, we reload the list of images when a new property is selected. We could do more to persist previously fetched images but we would need to do more cache invalidation. Right now, we have a decent trade-off between providing some level caching and keeping caching simple.
• The URLs for the images we are managing are a little unwieldy. This doesn't break anything but it means they are a little tough to read. Some type of tinyUrl solution to shrink the URLs might not be a bad idea.
• For flexibility image metadata is being stored in separate collections from the image itself. This results in a lot more database activity than if the data was stored together in a single table. For now, flexibility is most important, however, this could change over time. It would be straightforward to re-architect this.
• There are a whole world of options open to using the Exif data we are gathering. It would be nice to expose a bit of it in the GUI.
• We are not doing anything to filter properties based on being active or not. This might be desirable and is easily adjusted. Admins might want access to all properties and only want to expose active properties to users.

Final Words​

This wraps up our media-library series. Please don't hesitate to reach out if you have questions about the project - pete@fullsapps.com.

Background​

Not surprisingly we will leverage Firebase Hosting to host our application. This in one of the most straightforward operations related to our application.

Walk Through​

I am going to start by creating a production build of our application.

npm run build

There are some good bits in the create-react-app documentation about installing and using serve. This is a good way to test your production build before you push it to a live server.

See: https://facebook.github.io/create-react-app/docs/deployment.

The steps to deploy to Firebase Hosting are also discussed on that same page. Below are the steps we are using and the answers to the Firebase questions.

npm install -g firebase-tools
firebase login
firebase init
Are you ready to proceed? Yes
Which Firebase CLI features... Hosting
Select a default Firebase project for this directory: select your media-library project (this will be skipped after you do it once)
What do you want to use as your public directory? build
Configure as a single-page app (rewrite all urls to /index.html)? Yes
File build/index.html already exists. Overwrite? No

The result should be a url. In fact, you will get two urls. One links to the project in the Firebase Console. The more important url is the one that is the application itself.

My url is: https://ml-dev-18bc4.firebaseapp.com/

Your are welcome to register as a new user and try the application.

If you are interested in seeing the admin side of the application send me an email (pete@fullsapps.com) and I will make you an admin.

Next​

Let's wrap up in the next post with a quick postmortem and discussion about what could be done next with the application.

Code​

https://github.com/peterdyer7/media-library

Background​

For the most part this post is about pulling together a lot of the concepts we have applied elsewhere.

Walk Through​

Let's start by replacing our Images component placeholder with a component that will display all of the images for a selected property.

Before we create the component itself I want to create a helper component. I want to be able to let users filter the list of displayed images. We can use react-select to help. I'm going to create a generic component that uses react-select to allow us to generically identify a list for filtering.

import React, { useState, useEffect } from 'react';
import PropTypes from 'prop-types';
import Select from 'react-select';

export default function MultiSettingSelect({
  values,
  label,
  id,
  handleChange,
}) {
  const [options, setOptions] = useState([]);

  useEffect(() => {
    const temp = values.map((value) => ({ value: value, label: value }));
    setOptions(temp);
  }, []);

  return (
    <>
      <label htmlFor={id}>{label}</label>
      <Select
        id={id}
        name={id}
        options={options}
        isMulti
        onChange={handleChange}
      />
    </>
  );
}

MultiSettingSelect.propTypes = {
  values: PropTypes.array.isRequired,
  label: PropTypes.string.isRequired,
  id: PropTypes.string.isRequired,
  handleChange: PropTypes.func.isRequired,
};

With that done we can create the Images component itself. There are some things worth noting in this component. First, we are leveraging cards from Semantic UI React. This is a simple way to group "like" data. Second, this is where we are using the "small" image we are creating whenever an image is uploaded. It would not make sense to download and display the fullsize image on a card.

Next, notice the use of useEffect. As we have throughout this project we are using it to load data when the component is loaded. However, we are also using it in a more sophisticated way to manage how our filters are applied. If a user changes any filters (adds to or removes) it triggers useEffect to run and update the list of displayed images.

import React, { useState, useEffect } from 'react';
import PropTypes from 'prop-types';
import {
  Card,
  Image,
  Button,
  Segment,
  Header,
  Table,
  Grid,
  Dimmer,
  Loader,
} from 'semantic-ui-react';
import { Link } from 'react-router-dom';

import MultiSettingSelect from '../../../../UI/selects/MultiSettingSelect/MultiSettingSelect';
import * as routes from '../../../../../shared/constants/routes';

export default function Images({
  images,
  loading,
  error,
  propertyId,
  settings,
  boundImagesPropertyFetch,
  boundSettingsFetch,
}) {
  const [filteredImages, setFilteredImages] = useState(images);
  const [primaryCategoryFilters, setPrimaryCategoryFilters] = useState([]);
  const [secondaryCategoryFilters, setSecondaryCategoryFilters] = useState([]);
  const [tagFilters, setTagFilters] = useState([]);

  useEffect(() => {
    // TODO: consider looking through the state to see what images exist
    boundImagesPropertyFetch(propertyId);

    if (Object.keys(settings).length === 0) {
      boundSettingsFetch('imageMetadata');
    }
  }, []);

  useEffect(() => {
    let tempImages = images;

    let temp = primaryCategoryFilters.map((v) => v.value);
    if (temp.length > 0) {
      tempImages = tempImages.filter((image) =>
        temp.includes(image.primaryCategory)
      );
    }

    temp = secondaryCategoryFilters.map((v) => v.value);
    if (temp.length > 0) {
      tempImages = tempImages.filter((image) =>
        temp.includes(image.secondaryCategory)
      );
    }

    temp = tagFilters.map((v) => v.value);
    if (temp.length > 0) {
      tempImages = tempImages.filter(
        (image) => image.tags && image.tags.some((r) => temp.includes(r))
      );
    }

    setFilteredImages(tempImages);
  }, [primaryCategoryFilters, secondaryCategoryFilters, tagFilters, images]);

  if (error) {
    return <>Error! {error}</>;
  }

  if (loading || Object.keys(settings).length === 0) {
    return (
      <>
        <Dimmer active>
          <Loader />
        </Dimmer>
      </>
    );
  }

  return (
    <>
      <Segment>
        <Header size='medium'>Filters</Header>
        <Grid columns={3}>
          <Grid.Row>
            <Grid.Column>
              <MultiSettingSelect
                values={settings.primaryCategory}
                label='Category'
                id='primaryCategory'
                handleChange={(values) => setPrimaryCategoryFilters(values)}
              />
            </Grid.Column>
            <Grid.Column>
              <MultiSettingSelect
                values={settings.secondaryCategory}
                label='Alt Category'
                id='secondaryCategory'
                handleChange={(values) => setSecondaryCategoryFilters(values)}
              />
            </Grid.Column>
            <Grid.Column>
              <MultiSettingSelect
                values={settings.tags}
                label='Tags'
                id='tags'
                handleChange={(values) => setTagFilters(values)}
              />
            </Grid.Column>
          </Grid.Row>
        </Grid>
      </Segment>
      <Card.Group centered>
        {filteredImages.map((image) => (
          <Card key={image.name}>
            <Image
              src={
                image.repros
                  ? image.repros.small
                    ? image.repros.small
                    : image.url
                  : image.url
              }
              style={{ maxHeight: 220, objectFit: 'cover' }}
            />
            <Card.Content>
              <Card.Header>{image.caption}</Card.Header>
              <Card.Description>
                <Table celled compact definition>
                  <Table.Body>
                    <Table.Row>
                      <Table.Cell collapsing>Category</Table.Cell>
                      <Table.Cell>{image.primaryCategory}</Table.Cell>
                    </Table.Row>
                    <Table.Row>
                      <Table.Cell collapsing>Alt Category</Table.Cell>
                      <Table.Cell>{image.secondaryCategory}</Table.Cell>
                    </Table.Row>
                    <Table.Row>
                      <Table.Cell collapsing>Tags</Table.Cell>
                      <Table.Cell>
                        {image.tags && image.tags.join(', ')}
                      </Table.Cell>
                    </Table.Row>
                  </Table.Body>
                </Table>
              </Card.Description>
            </Card.Content>
            <Card.Content extra>
              <Button
                basic
                as={Link}
                to={`${routes.PROPERTIES}/${propertyId}${routes.IMAGES}/${image.id}`}
              >
                Details
              </Button>
              <Button basic as='a' href={image.url} download>
                Download
              </Button>
            </Card.Content>
          </Card>
        ))}
      </Card.Group>
    </>
  );
}

Images.propTypes = {
  images: PropTypes.array.isRequired,
  loading: PropTypes.bool.isRequired,
  error: PropTypes.string.isRequired,
  propertyId: PropTypes.string.isRequired,
  settings: PropTypes.object.isRequired,
  boundImagesPropertyFetch: PropTypes.func.isRequired,
  boundSettingsFetch: PropTypes.func.isRequired,
};

We will also create a corresponding container component.

import { connect } from 'react-redux';

import Images from '../../../../../components/user/Properties/Property/Images/Images';
import { imagesPropertyFetch } from '../../../../../shared/redux/actions/images';
import { fetchSettings } from '../../../../../shared/redux/actions/settings';

const mapStateToProps = (state, ownProps) => ({
  images: state.images.images.filter(
    (image) => image.properties.includes(ownProps.propertyId) && image.active
  ),
  loading: state.images.loading,
  error: state.images.error,
  settings: state.settings.settings,
});
const mapDispatchToProps = (dispatch) => ({
  boundImagesPropertyFetch: (id) => dispatch(imagesPropertyFetch(id)),
  boundSettingsFetch: (type) => dispatch(fetchSettings(type)),
});

export default connect(mapStateToProps, mapDispatchToProps)(Images);

Next, we can replace our Image component placeholder with a component that displays more information about a selected image. For the time being I am going to reuse some of the component we used on the AdminPropertyImage component.

There is one extremely frustrating issue with this component (at least troubleshooting it was tricky). In this component I am using the Image component from Semantic UI React. That creates a name conflict with the component itself. It is easy to workaround this by renaming the Semanic UI React component but until I recognized there was a name conflict I was seeing some very strange behavior.

import React, { useEffect } from 'react';
import PropTypes from 'prop-types';
import {
  Grid,
  Segment,
  Button,
  Container,
  Dimmer,
  Loader,
  Image as SemanticImage,
} from 'semantic-ui-react';
import { Link } from 'react-router-dom';

import ConfigurableMetadata from '../../../../UI/images/ConfigurableMetadata/ConfigurableMetadata';
import ReadOnlyMetadata from '../../../../UI/images/ReadOnlyMetadata/ReadOnlyMetadata';
import SafeSearch from '../../../../UI/images/SafeSearch/SafeSearch';
import Labels from '../../../../UI/images/Labels/Labels';
import * as routes from '../../../../../shared/constants/routes';

export default function Image({
  image,
  loading,
  error,
  boundImageFetch,
  match,
}) {
  useEffect(() => {
    if (!loading) {
      boundImageFetch(match.params.imageId);
    }
  }, []);

  if (error) {
    return <>Error! {error}</>;
  }

  if (loading || Object.keys(image).length === 0) {
    return (
      <>
        <Dimmer active>
          <Loader />
        </Dimmer>
      </>
    );
  }

  return (
    <>
      <Container>
        <Button
          content='All Images'
          icon='left arrow'
          labelPosition='left'
          as={Link}
          to={`${routes.PROPERTIES}/${match.params.propertyId}${routes.IMAGES}`}
        />
        <Grid stackable padded columns={2}>
          <Grid.Row>
            <Grid.Column>
              <Segment>
                <SemanticImage src={image.url} />
              </Segment>
              <Segment>
                <Button basic as='a' href={image.url} download>
                  Download
                </Button>
              </Segment>
              <Segment>
                <ConfigurableMetadata image={image} />
              </Segment>
              <Segment>
                <ReadOnlyMetadata image={image} />
              </Segment>
            </Grid.Column>
            <Grid.Column>
              <Segment>
                <SafeSearch safeSearch={image.safeSearch} />
              </Segment>
              <Segment>
                <Labels labels={image.labels} />
              </Segment>
            </Grid.Column>
          </Grid.Row>
        </Grid>
      </Container>
    </>
  );
}

Image.propTypes = {
  image: PropTypes.object.isRequired,
  loading: PropTypes.bool.isRequired,
  error: PropTypes.string.isRequired,
  boundImageFetch: PropTypes.func.isRequired,
  match: PropTypes.object.isRequired,
};

We will also create a corresponding container component.

import { connect } from 'react-redux';

import Image from '../../../../../components/user/Properties/Property/Image/Image';
import { imageFetch } from '../../../../../shared/redux/actions/images';

const mapStateToProps = (state) => ({
  image: state.images.selectedImage,
  loading: state.images.loading,
  error: state.images.error,
});

const mapDispatchToProps = (dispatch) => ({
  boundImageFetch: (imageId) => dispatch(imageFetch(imageId)),
});

export default connect(mapStateToProps, mapDispatchToProps)(Image);

I will update the Property component to render the container versions of Images and Image. Also, I want to refactor the Property component (and its container component). I was previously loading images and settings on this page. I am going to pass that responsibility down to the rendered components themselves (we did that above). This does a lot to simplify the Property component itself and it actually makes the rendered components (Images and Image) easier to reason about as well as they are getting the data they need from their own containers.

import React, { useEffect } from 'react';
import PropTypes from 'prop-types';
import {
  Menu,
  Button,
  Header,
  Dimmer,
  Loader,
  Container,
} from 'semantic-ui-react';
import { Link, NavLink, Switch, Route, Redirect } from 'react-router-dom';

import Detail from './Detail/Detail';
import ImagesContainer from '../../../../containers/user/Properties/Property/Images/ImagesContainer';
import ImageContainer from '../../../../containers/user/Properties/Property/Image/ImageContainer';
import * as routes from '../../../../shared/constants/routes';

export default function Property({
  property,
  error,
  loading,
  match,
  boundPropertyFetch,
}) {
  useEffect(() => {
    if (!property) {
      boundPropertyFetch(match.params.propertyId);
    }
  }, []);

  if (error) {
    return <>Error! {error}</>;
  }

  if (loading || !property) {
    return (
      <>
        <Dimmer active>
          <Loader />
        </Dimmer>
      </>
    );
  }

  return (
    <>
      <Container>
        <br />
        <Button
          content='All Properties'
          icon='left arrow'
          labelPosition='left'
          as={Link}
          to={routes.PROPERTIES}
        />
        <Header as='h3' textAlign='center'>
          {property.name}
        </Header>
        <Menu pointing secondary>
          <Menu.Item
            name='Images'
            as={NavLink}
            to={match.url + routes.IMAGES}
          />
          <Menu.Item
            name='Details'
            as={NavLink}
            to={match.url + routes.DETAILS}
          />
        </Menu>
        <Switch>
          <Route
            path={match.url + routes.IMAGES}
            exact
            render={() => (
              <ImagesContainer propertyId={match.params.propertyId} />
            )}
          />
          <Route
            path={routes.PROPERTY + routes.IMAGE}
            component={ImageContainer}
            //render={() => <ImageContainer />}
          />
          <Route
            path={match.url + routes.DETAILS}
            render={() => <Detail property={property} />}
          />
          <Redirect to={match.url + routes.IMAGES} />
        </Switch>
      </Container>
    </>
  );
}

Property.propTypes = {
  match: PropTypes.object.isRequired,
  property: PropTypes.object,
  error: PropTypes.string.isRequired,
  loading: PropTypes.bool.isRequired,
  boundPropertyFetch: PropTypes.func.isRequired,
};

import { connect } from 'react-redux';

import Property from '../../../../components/user/Properties/Property/Property';
import { propertyFetch } from '../../../../shared/redux/actions/properties';

const mapStateToProps = (state, ownProps) => ({
  property: state.properties.properties.filter(
    (property) => property.id === ownProps.match.params.propertyId
  )[0],
  loading: state.properties.loading,
  error: state.properties.error,
});
const mapDispatchToProps = (dispatch) => ({
  boundPropertyFetch: (id) => dispatch(propertyFetch(id)),
});

export default connect(mapStateToProps, mapDispatchToProps)(Property);

I will create a simple component to display our configuration metadata in a way that doesn't allow it to be edited. For now, we are limited standard users to view-only.

import React from 'react';
import PropTypes from 'prop-types';
import { Header, List } from 'semantic-ui-react';

export default function ConfigurableMetadata({ image }) {
  return (
    <>
      <Header content='Configurable metadata' size='medium' />
      <List>
        <List.Item>
          <List.Header>Category</List.Header>
          {image.primaryCategory}
        </List.Item>
        <List.Item>
          <List.Header>Alt category</List.Header>
          {image.secondaryCategory ? image.secondaryCategory : <br />}
        </List.Item>
        <List.Item>
          <List.Header>Tags</List.Header>
          {image.tags ? image.tags.join(', ') : <br />}
        </List.Item>
      </List>
    </>
  );
}

ConfigurableMetadata.propTypes = {
  image: PropTypes.object.isRequired,
};

I have also done some refactoring to move components to more logical locations.

Next​

This is really the key place we have been driving to in this series of posts. We wanted to get to the point where we had a prototype application suitable for sharing with users to be able to engage with them and gather feedback. We will pause on creating any more code at this point and turn our attention to posting the application and capturing any information that might be helpful when we pick up coding in the future.

Code​

https://github.com/peterdyer7/media-library/tree/41.Images

Background​

There is one new concept I want to introduce in this post. When we display property details I want to display a map with the location of the property. I've decided to use Leaflet, and the React helper library React-Leaflet. In my opinion Leaflet is the best open-source option for displaying the map we want.

https://react-leaflet.js.org/ https://leafletjs.com/

Walk Through​

Let's start by create the property container to pull in the bits of the store we will need. We want a specific property, its images and the settings. Notice that we are using ownProps to leverage the property ID from the url to filter on a specific property.

import { connect } from 'react-redux';

import Property from '../../../../components/user/Properties/Property/Property';
import { propertyFetch } from '../../../../shared/redux/actions/properties';
import { imagesPropertyFetch } from '../../../../shared/redux/actions/images';
import { fetchSettings } from '../../../../shared/redux/actions/settings';

const mapStateToProps = (state, ownProps) => ({
  property: state.properties.properties.filter(
    (property) => property.id === ownProps.match.params.propertyId
  )[0],
  propertyLoading: state.properties.loading,
  propertyError: state.properties.error,
  images: state.images.images.filter(
    (image) =>
      image.properties.includes(ownProps.match.params.propertyId) &&
      image.active
  ),
  imagesLoading: state.images.loading,
  iamgesError: state.images.error,
  settings: state.settings.settings,
});
const mapDispatchToProps = (dispatch) => ({
  boundPropertyFetch: (id) => dispatch(propertyFetch(id)),
  boundImagesPropertyFetch: (id) => dispatch(imagesPropertyFetch(id)),
  boundSettingsFetch: (type) => dispatch(fetchSettings(type)),
});

export default connect(mapStateToProps, mapDispatchToProps)(Property);