It supports both key-value entries and documents.
That means that a field can contain a single value, such as a string or a number, but can also contain a document, i.e. a JSON-object.
🔹DynamoDB (2/3)
It's schemaless, so besides a key, it doesn't rely on a predefined schema.
You can think of this as a combination of relational and document-based databases such as MongoDB.
🔹DynamoDB (3/3)
It's fully managed by AWS, so you don't need a server running to host the database.
This enables extremely high flexibility when it comes to up- and down-scaling your solution.
GraphQL is a query language and an alternative to SQL and MySQL.
With GraphQL we can specify exactly what we need and the relation between the data coming from the backend, all in a single request.
AWS has a solution called AppSync which enables you to create a managed GraphqQL layer to securely access, write, and combine data from one or more data sources.
You can link a DynamoDB table as a data source directly, without having to write custom resolvers.
🔹GraphQL (3/3)
AWS AppSync is again fully managed, so you don't need a server running your GraphQL API.
Additionally, you can easily configure authentication based on an API-Token or OAuth 2.
AWS Lambda functions enable you to write the entire Back-End using individual functions that run in the Cloud.
This is an extremely powerful alternative to managing and provisioning servers for your Back-End.
🔹AWS Lambda (2/2)
Even though you can link a DynamoDB table as a data source directly using AppSync, you typically need a bit more custom resolver-logic.
Fortunately, you can use Lambda as a data source as well.
This allows us to write custom resolvers when needed.
🔸React (1/2)
React is a JavaScript library for building user interfaces.
It's especially powerful for writing Single Page Applications.
It's very little likely that you haven't heard of it already, but if not, I'll drop a link to their website here.
Additionally, it can be of great importance to understand where to use caching effectively.
How and where to cache very much depends on the application you're building.
In this article, I cover the different options and the pros/cons for each:
The biggest takeaway from this stack, is that it's serverless!
🔥 No need to manage servers.
🔥 Pay-per-use instead of paying for uptime.
🔥 Serverless is inherently scalable.
🔥 Reducing cost.
🔥 Energy-efficient, ultimately better for the climate.
I hope you enjoyed reading.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Contributing to Open-Source can be an important career move!
It will signal that you're great at collaborating - a skill that is even more important than being good at coding!
If any questions or problems arrises, my DM will be open.
Happy hacking!
On Twitter API Client
1️⃣ Add tweet_mode parameter
2️⃣ Store credentials per instance to allow multiple clients.
Keep these in mind when you start writing 👇
Checklist, rules, and recommendations 🧵
(Repost)
Decide on:
☑️ Subject: What are you writing about?
☑️ Target: Who are you writing for?
☑️ Goal: What do you want to achieve?
☑️ Tone: How do you want to come across?
Checklist:
✅ Do you have a short and precise headline?
✅ Do you have an enticing introduction?
✅ Do you fulfill a promise in the conclusion?
✅ Do you have a "tweetable" wrap-up?
✅ Is your language colorful and interesting?
✅ Do you apply pathos/ethos/logos?
Keep these in mind when you start writing 👇
Checklist, rules, and recommendations 🧵
Decide on:
☑️ Subject: What are you writing about?
☑️ Target: Who are you writing for?
☑️ Goal: What do you want to achieve?
☑️ Tone: How do you want to come across?
Checklist:
✅ Do you have a short and precise headline?
✅ Do you have an enticing introduction?
✅ Do you fulfill a promise in the conclusion?
✅ Do you have a "tweetable" wrap-up?
✅ Is your language colorful and interesting?
✅ Do you apply pathos/ethos/logos?