Not exactly. It is faster persist flat files of json to a CDN and fetch those files than a database. However, as you have mentioned this does not work great for search.
My professional recommendation for search is https://opensearch.org/. Open Search is the open source predecessor of elastic search offering several new features. Not to plug aws more than I already have but AWS has also replaced their search service with a production grade managed open search solution: https://docs.aws.amazon.com/opensearch-service/. Search is an area though where it is difficult to achieve zero cost. However, I think the pure power of open search out weighs the cost factor which isn’t terribly expensive.
However, if you are seeking a low cost alternative that works well with s3 AWS Athena: https://aws.amazon.com/athena. With Athena you can consume unstructured data in mass quantities and catalog it as structured data. Once cataloged SQL can be used to query the info. The very nice part of this service is it is serverless with a pay for use model instead of time. The amount of free queries and data transfer is probably more than enough for many apps.
These are some other high profile search solutions which I have also really liked.
- Typesense: https://typesense.org/
- Algolia: https://www.algolia.com/
Again though not incredibly cheap to run a production grade cluster. However, all of these are highly available, auto scaling cloud solutions unlike a single db instance.
Correct. One of the advantages of amazon is any services api can be used directly in the browser securely. This eliminates the need for both a database and server entirely for modern JavaScript browser native applications like React, Angular, Vue, etc. You can merely implement services as needed to take the place of a relational database, email, queue, etc. All with generous free tiers on aws.
Building an application to start with production grade performance, low latency, scalability, robustness, flexibility, and cost is well thought architecture. What is not great is building an application in isolation of these things and just tossing it up on a server. Distributing responsibilities of an application across services specific to use case is responsible well intended design. Slimming down traditional stacks by completely removing servers and databases is environmentally responsible software architecture.
I have dedicated myself to AWS which offers more than enough to achieve just about anything and is a highly coveted skill in the industry. However, I am intrigued by some things firebase offers. I think the aws free tier surpasses all vendors out there. You can do a lot for free in AWS. The free tier does end after a year but that is only for a the account. Nothing stops you from creating another separate account and migrating resources over there. This model effectively creates a lifetime of free tier on aws.
One thing I really like about aws is being able to securely call all the rest apis with fine grained access control directly in the browser. This completely eliminates the needs for servers. Instead applications can be built as mere JavaScript apps that run completely in the browser and communicate with the cloud directly. Eliminating servers is a key aspect in reducing ongoing infrastructure costs and reducing world wide energy consumption.
This mentality is one I’ve been researching and experimenting for a while. Running enterprise grade JavaScript apps without servers as inexpensive as possible without sacrificing latency, scalability, security, and overall performance.
There are a lot of options for this even relational databases using AWS App Sync https://aws.amazon.com/appsync/. In App Sync you can run secure fine grained access controlled graph queries directly from the browser to consume and persist data to relational databases. App Sync is pretty neat if you have an existing relational database but would like to spend less time redesigning data storage and more time focusing on delivering a modern web experience for users using a JavaScript app.
At work I have floated around the idea of using App Sync since we are somewhat married to a relational database. We currently run a grails app (MVC) Java rest API with a JavaScript browser app. The MVC rest api can be eliminated an replaced with App Sync graph queries directly in the browser instead. Completely eliminating an entire tier from our stack. This is the same for any modern JavaScript front-end app that relies on a proprietary rest api.
This demo puts some of these into action. In particular running a JavaScript app in the browser without any servers that communicates directly with aws s3 and open search rest api. Opening the network tab will reveal fetches to s3 and open search using secure signed http requests that enable fine grained access control of resources and operations in aws. This is a fairly new concept in the industry known as 0 trust and all AWS rest APIs and asset linking support it.
That entire page is actually configurable via an editor.
When saved the page is stored inside s3 as a json file. There is also a partial copy inside open search. The previous page matches routes using open search queries. All this is achieved directly in the browser. No servers except for those running the open search cluster which at the moment is only a single node.