
## Short story

Before to begin the **"how to"** just would like to give a brief story on **"why"** I had to make it.

While I was putting my blog online again and trying to use this nice feature from Next.js to generate the OG images for each of my blog posts, the [recommended way](https://vercel.com/docs/concepts/functions/edge-functions/og-image-generation) to do it, is basically adding an endpoint(e.g.: `pages/api/og.tsx`) that can take advantage of the `ImageResponse` class from `@vercel/og`.

That's ofcourse if you're not using the new `app` folder in [Next.js 13](https://nextjs.org/docs/app/building-your-application/routing).

Everything seemed great, until my last post didn't quite generate properly the OG image and I couldn't find any way to debug it, because locally it was working, but only inside Vercel hosting itself was returning [200 OK](https://http.cat/200) without any image.

![200 OK](https://http.cat/200)

Because of lack of way to debug it in "production", I opened an [issue on Github](https://github.com/orgs/vercel/discussions/3432#discussioncomment-6607542) trying to get some support.

Question is still open at moment of writting this blog post (August 15th, 2023).

I'm not quite a fan of broken stuff, so I started to wonder how I could fix it, after giving up on the current approach.

That concludes the **why** section.

## Generate Image

Despite being the recommended way of doing such thing from Next.js docs, I had couple of doubts with such approach.

> What is someone abused my endpoint?

> Why it needs to be "dynamic" if I won't be chaning that much the metadata of it?

These were the big "?" I always had, then I thought about static generation of those, but that would be a tedious work for every blog post, specially for old ones (due to migration).

So, I had it working, with `ImageResponse`, basically I had to make my own `ImageResponse` and that's it.

Vercel docs, had a session of [Technical details](https://vercel.com/docs/concepts/functions/edge-functions/og-image-generation#technical-details) where it highlight the amazing library: [Satori](https://github.com/vercel/satori) which allow us to generate an SVG based on JSX markup.

Until this point, I could simply reuse basically 90% of what I have done already, but there was one last thing that it was missing...

Satori just renders an SVG, but I need a PNG file to be saved, for that I found [resvg-js](https://github.com/yisibl/resvg-js) which seems to be a wrapper on [Resvg](https://github.com/RazrFalcon/resvg/) which is a Rust based high-performance SVG renderer and toolkit(in short: it will generate the PNG based on our SVG).

And guess what? That's basically what the ImageResponse does behind the scenes.

Ok, tools in place.

![Yay celebration gif](/static/img/posts/next-og-build/yay.gif)

```tsx title="lib/og-generator.tsx"
import satori from 'satori'
import { Resvg } from '@resvg/resvg-js'
import { writeFile, readFile, stat } from 'fs/promises'
import { join } from 'path'

type ImageOptions = {
  width: number
  height: number
}
type GenerateImageArguments = {
  outputName: string
  options: ImageOptions
}
export async function generateImage({
  outputName,
  options
}: GenerateImageArguments) {
  const publicPath = 'public'
  const relativePath = `og-images/${outputName}.png`
  const pngPath = join(process.cwd(), publicPath, relativePath)
  ...
  const og = /* template */
  const svg = await satori(og, {
    width: options.width,
    height: options.height,
    fonts: [],
  })
  const resvg = new Resvg(svg)
  const pngBuffer = resvg.render().asPng()

  await writeFile(pngPath, pngBuffer)

  return relativePath
}
```

This is a simplified version of it, because we have to deal with Fonts as well, I did the easiest way for the given time:

- Go to [Google Fonts](https://fonts.google.com/)
- Choose a font (in my case Inter)
- Download it and Unzip it
- Place it inside `fonts` folder
- Load it

```tsx title="lib/og-generator.tsx"
import { writeFile, readFile, stat } from 'fs/promises'
import { join } from 'path'
...
const fontPath = 'fonts'
const interPath = join(
  process.cwd(),
  fontPath,
  'Inter/static/Inter-Regular.ttf'
)

export async function generateImage({
  outputName,
  options
}: GenerateImageArguments) {
  ...
  const interFont = await readFile(interPath)
  ...
  const svg = await satori(og, {
    width: options.width,
    height: options.height,
    fonts: [
      {
        name: 'Inter-Regular',
        data: interFont,
        weight: 400,
        style: 'normal',
      },
    ],
  })
  ...
}

```

After that, our fonts are loaded. with that our tempalte should work and be based on the choosen font.

That should be enough code to make your own `generateImage` method, of course you must implement on your own the template, but I guess that should be the easiest part from now.

> You can take a look on the full code on my [Github repository](https://github.com/thebergamo/www/blob/main/lib/og-generator.tsx#L46-L124)
>
> In my case it's a bit more complex due to some other use cases I would like to handle.

You can grab some inspiration from [OG Image Playground](https://og-playground.vercel.app/) (it works with Tailwind, so yay 🎉)

## Include into Pages

Once, our `generateImage` method is created we can move to how to add it to our pages.

I think the most interesting one is the one inside my `pages/blog/[slug].tsx`, so I will quote this one.

So, what is the trick? I will use the `getStaticProps` method to generate my static image and pass the generated reference into my `BlogPage` component.

Take a look into the snippet:

```tsx title="pages/blog/[slug].tsx"
type Props = {
  ...
  ogImage: string
}

function BlogPage({ ogImage, ...props}: Props) {
  ...
  return (
    <>
      <NextSeo
        openGraph={{
          ...
          images: [
            {
              url: ogImage,
              width: 1200,
              height: 630,
              type: 'image/png'
            }
          ]
          ...
        }}
      />
      ...
    </>
  )
  ...
}

export async function getStaticProps(props) {
  ...
  const post = /* get your post */
  const ogImage = await generateImage({
    ...,
    outputName: `${locale}_${post.slug}`,
    options: {
      width: 1200,
      height: 630,
    }
  })

  return {
    props: {
      ...,
      ogImage
    }
  }
}
```

> Again, this is an oversimplified version of my own code, take a look into my repository for [full version](https://github.com/thebergamo/www/blob/main/pages/blog/%5Bslug%5D.tsx).

That's it, with this code we should be able to generate the images for all static pages that we would like.

In case of my blog posts, it's important to remember to use the `getStaticPaths` that I omited for brevity.

> 💡 In this case, remember to place the output dir of these images in the .gitignore.
>
> That's interesting, because if you changed anything, the new image will be generated in every deploy.
>
> As a side effect your build will be also longer if you have quite a big list of pages to generate them.

As we know, `getStaticProps` is called for our static generated pages, so this method will be called and these OG images would be generated and saved for us automatically in each build.

## Side effect...

There is one side effect that it's important to be aware, I wasn't really that concerned with image sizes until I rolled [this change](https://github.com/thebergamo/www/pull/2).

That basically created a quite big zip file that was exceding Vercel limits under the Free Plan.

In order to fix that, I used [Tiny PNG](https://tinypng.com/) to remove any extra bytes from my images, so the final bundle version was smaller and also the generated images were smaller too.

That happened because, I also added couple of images(covers of the blog posts) as part of the OG image, after srinking the images I was again back under Vercel limits and being a good citizen 😻.

### That's it folks!


From issue with recommended method for generating OG images to statically generated ones at build time. Check it out!

Create Next.js Open Graph(OG) images at build time


> This post was originally an internal talk I gave at EPAM. Usually while giving a talk I like to write up a bit on what I would like to talk… so here we are :)

## Introduction

Micro-Frontends are not exactly something new, but I believe it gets lately more attention because, Front-End applications are getting more complex every year.

As before we had such a revolution with Micro Services, when the backend services emerged from a “well organized IT room cables” that had to be even. more organized, the Micro Frontends have their prom lately.

I have had in the past years inside EPAM to work in couple of products/teams that were in touch with such subject but in most cases, we’re not even calling it Micro Frontends, but rather “Portals” for internal applications.

And in a previous assignment I had the pleasure to design and implement our own Micro-Frontends architecture, but with focus on the framework itself and that’s exactly what I would like to dive with you today.

## Decision Framework

![Decision Framework](/static/img/posts/mfe/decision-framework.webp)

> Image Source: [From Luca Mezzalira post](https://lucamezzalira.medium.com/micro-frontends-decisions-framework-ebcd22256513)

I will show you today a simplified architecture of what exactly was done back then, but I think you will get the point, if not, by the end I will try to answer any of your questions.

### Building Blocks

As of many applications, in order to build something bigger basically we must start with the basic building blocks that we have and need to do it.

In most cases, the main building blocks are:

1. An App Shell
2. A Router/Orchestrator
3. A “messenger”

Of course you could have other capabilities that would be useful for your Micro-Frontend to go to production, but those are the most important ones from my experience.

### App Shell

The Application shell is usually responsible to control some key aspects of your application, as it is usually the part that would manage things on the Client Side. - But Marcos, what about Server Side Micro Frontends? - Glad you asked Marcos, great listener 🙂

Let’s talk about it after the building blocks, so lets put a pin on it.

At least in the MF Framework/Server I built the App Shell had many responsibilities all together as it was wrapping the micro-frontends, responsible for client side orchestration in general.

It was responsible to load most of the common assets, for instance we had an internal Design System using Web Components.

Yes, we used Web Components on the Design System level and you know what? Adopt React, Angular, Vue or any other thing if you can.

Things will be easier for the whole team, unified tooling, common language among developers and so on. We love to embrace freedom to choose our own tools, but Web Components have potential to create some burden that it might not worth it.

So, in general your App Shell would be the boot loader of your MFs, keep it clean, provide modular functionalities to it to enhance the experience of other Micro frontends would be damn helpful.

Some other alternative could be to create some kind of SDK (a big one such as AWS SDK v2, or a more modular like v3, the JS one of course I mean).

That could give you some flexibility to your MF applications, but at the same time it could create a bit of trouble…

Do the application need to embed the sdk? What about never versions vs old version? Deprecations? Major releases with breaking changes?

In general, specially with a big number of dependant applications, avoid Breaking changes whenever you can, but this applies to everything not only in MF cases.

In most cases you could make them part of the injected libs from your Application shell, so your users don’t need to pay the toll for this dependencies.

**In Summary**

- App Shell is the first thing your client would receive
- It will be responsible to inject and provide the shared capabilities and libraries to others
- It is responsible for most of the work on the client side
- Smaller footprint app shell means faster startup

### Router/Orchestrator

Your app shell will prepare the stage for the show to begin, but you need a MC to get the show started.

Who is available? Who is next? Where is that MF?

There are couple of possibilities on how you can orchestrate a Micro Frontend same for the app shell composition of those pages, but I want to focus on the one I used.

We decided to take a “Vertical split” for the micro frontends to be served, so they could be responsible for their whole flow and the development closer to regular SPAs as possible.

So, in this case our Server Application was responsible to based on the requested “path” to choose the correct MF and add it to the page.

No Module Federation or anything was available, so we basically while building the “index.html” based on our template and after resolving which MF should be loaded, we embedded the “app.js” and any other asset it required to be loaded.

And our orchestrator was the responsible of resolving it.

We had some flexible configuration files for each MF that many things could be changed and the Orchestrator understand and to the necessary things to be ready.

### The “messenger”

If this talk were done in Brazil I would probably change “Messenger” to WhatsApp to have a quick pun intended, but well in Poland the most used as far as I know is the other one from Facebook.

The main goal in here is to have a way to those Micro Front ends to communicate.

In our case, we didn’t have much need of such communications as the Micro frontends did not communicate that much between each other, but rather some shared capabilities that we developed as separated micro-frontends were that needed.

In general, I believe the most recommended way to handle such case is following the same recommendations of MicroService world and have an Event based architecture so we can have a loose coupled architecture between the MFs.

Won’t dive that much into this area as I haven’t touch it that much, but the most challenging part here is about creating some patterns and contracts that could be followed by all the teams to avoid conflicts between services and wrong messages flowing around.

So, before services communicating, better let the people talk.

### The Decision framework

I have talked about this 3 main building blocks that from my experience were the most useful, but how do I came to those?

Back then, it was basically some patterns that I have seem in other applications were using and a bit on structuring and gut feeling, but nowadays we have much more research and structure to be based.

One of the known names in the Micro-Frontends space is Luca Mezzalira and he also wrote a really insightful book about it.

He created the Micro-Frontends decisions framework as you can see in this picture.

Well, he split the points into 4 decisions in order to build your framework.

1. Definition
2. Composition
3. Route
4. Communication

Don’t want to be too much repetitive in here, but it is kind of the building blocks I showed previously, but want to go a bit more in details in some aspects I skipped earlier.

### Definition

Basically we need to define how the Micro-Frontends would be created?

Is a team responsible for a set of components of a page? (Horizontal)

Or is a team responsible for the whole page? (Vertical)

Here is a way we want to create the boundaries between the teams in a horizontal split, you can have some granularity on what exactly your team would work with and not necessarily build some “components” that not necessarily are important for your team.

For instance, let’s imagine the YouTube page, if you’re part of the Player Team, you not necessarily would need to know about the recommendation widget or other parts that won’t aggregate that much other than the player.

So you can leave such expertise to other team and be focused on one part of the domain.

Some other way around is for example if your teams are split in the development of those pages and some micro apps inside the whole application. So, the vertical split would make more sense in this area and in fact in some cases it would even be closer to the SPA development that we’re used to. it.

So, there are many pros and cons on that, but it would depend mostly on how the domains in your company are split.

In my case, it made more sense to let the MicroFrontends being isolated from the beginning and the level of integration was vertical.

### Composition

How the views and apps are getting composed?

And in here it comes with a mix of “previous” too components that we talked in some situations. In general we have 3 possible splits nowadays.

**Client Side**

Starting from the client side, we’re talking about the App Shell being fully responsible to understand the context it is and load the correct micro-frontends to the correct places, so despite your previous choice, in case this is the choice for composition, having a smarter app shell would be the case in here.

And there are many techniques to be applied in here, for example loading the MFEs as iframes such as Luigi Framework or if you are not big fan of iframes, you could take a look on how Single SPA is solving this part.

Single SPA for example have a way to use any framework you wish as far you implement the Single SPA lifecycles for your MFE then it will do the composition to you.

**Server Side**

Moving to the server side, your server must be responsible to understand where the MFEs are and how to put everything together.

Same as my previous case where I mentioned the Orchestrator, it should understand that the “client” is requesting some portion of the page or the whole page and things should be rendered on the server for being rehydrated later on the client if needed.

Something similar to the App Shell, but running on the backend. (that seems to be to obvious)

In general most of the solutions in many cases falls into the same principles as a Layout “parser” if you have worked with this template libraries before Angular and React were cool, that would be basically a “more complex” version of those as the process would be the same.

Parsing a template, identify dependencies, load them and build it.

**Edge Side**

Edge Side is not new also, as there is something called Edge Side Includes or ESI that is a small markup language to be used inside CDNs that basically is a way to compose those templates too.

To be honest, I won’t go further in this direction of the ESIs because despite being around for over 20+ years it didn’t got that much traction, maybe it was too much ahead of its time.

Let's rather focus on the capacities we have nowadays with Cloudflare Workers, Vercel and Labda@Edge are better technologies to think about.

Again, no big news in here, for me it is basically a limited Server Side option as of now (but for sure would be much improved sooner) that is closer to your end user.

So most of Server Side applies here.

### Routing

Again, Client Side, Server Side and @Edge.

To not deviate much I believe in here, best is to keep in sync with previous decision and do the routing aligned with the composition.

In the case of my project we decided to do the hard work on the server side, it was easier because of the vertical split, so our router just needed to load the MFE based on the url was pointed and from that point the internal routing of the app was based on their own SPA router.

That brings some interesting challenges on for example, how we’re sure that the application won’t have a link to a different MFE assuming it would load it’s own and stay in the correct place after some “refresh”?

### Communication

Just to be brief in here again, best would to combine a single mechanism to dispatch messages to communicate between those MFEs and it could be combined with URL for cases when you want to also pass those messages after some full refresh or requesting also some trigger on the backend.

For example in my current project, we’re using some internal MFE framework that loads those MFEs completely independent and it would be hard to pass messages around without some BE integration, the way to mitigate it a bit was introducing some passing messages by URL using some query params to be used something like JSURL or you can also go wild and use JSON with base64 encodings, up to you 🙂

When you have this App Shell in place and you can control these messages in the browser to being passed and kept, use some Event-Emitter, Event Bus or even Custom Events and be happy.

## Available Tools

There are many great frameworks out there that can help you to use most of the options chosen during the decision framework.

So don’t be afraid of explore them and check if those requirements would fit in your use case before deciding to build your own.

Some of the ones I would like to highlght in this session are:

- [Module Federation](https://module-federation.github.io/)
  It’s was initially a webpack plugin that went bigger and now its creator is making many ports for it to be used and available everywhere, so it worth to take a look and build on top of it when it makes sense.
  For me to be honest, if you just need a simple way to resolve multiple apps and compose them all together into a bigger application it would be a great choice and even more complexes integrations can be built on top of it as it would do the hard lifiting of lazy loading those remotely.
- [TailorX](https://github.com/StyleT/tailorx)
  Still on the smaller libraries to get started faster, TailorX would give you ability to build and parse your templates and serve them quite fast, so composing would be easier.
  If I would build something that is custom right now, I would use TailorX as a base line for the orchestrator and initial layouts as it is easy and integrate easily with other tools, so pretty much easy to expand it’s capabilities.
- [Single SPA](https://single-spa.js.org/)
  As mentioned, Single SPA is also a good option in here and it does have already many features out of the box that can fit most of use cases of MicroFrontends.
- [Isomorphic Layout Composer](http://ilc.namecheap.technology/)
  Think about Single SPA + TailorX best of both words so ILC wraps around those great tools to make your life easier too.
  Besides, Built-in registry, framework agnostic and so on
- [Open Components](https://opencomponents.github.io/)
  Besides creating the composition of those MFEs we have other challenges like, how to find those MFEs in the wild? Moving forward with other more complete tools, we have OC that also make available a registry for your MFEs which makes much easier to have the full flow in here.
- [Piral](https://piral.io/)
  On the complete solutions, Piral offers you also a great solution end to end to your MFEs so you don’t need to extend that much up front and can get started faster, so just extend as your requirements need and manage around extensions of Piral.
  I could go further as there are many tools available in a lot of specifics, but let me move forward 🙂

## Build or Buy

So, the Build or Buy question is always important in such cases, well, not exactly buy but rather using something that already exist.

Because on the developer heart, it is always funnier to create your own tool, specially that we always think that our use case is unique.

Well, if we think deeper our uniqueness is in general 10% of the general use cases, so my recommendation is to try to find the tools that solve most of the common use cases, but instead of re-creating the wheel, try to extend and evolve current tools available.

That’s at least how I approach most of those cases and based on my experience inside EPAM it is pretty much similar.

So in this block I would rather talk about a bit of the challenges we’re about to check before looking into a fully custom solution.

For the sake of this presentation I would like to hightlight two points that I consider fairly important for adoption inside organizations.

### DX

One of the key successes of our previous project adoption was that we focused on an easy way for developers to get started to use our framework, so tooling and documentation was easy enough to get started.

We used a lot generators to bootstrap applications, simple to use CLI and ability to run the application locally with fully infrastructure the same as in the higher environment.

There were a use case that one specific team in a business unit of our customer, wanted to have our “server” running inside their custom infrastructure due to some specifics of their product, so they did without much trouble because our “server” was already ready to be used with docker and even with a more complex deployment they had it wasn’t a big challenge because our DX was simple to be used and production ready even in local development.

Besides of it, we had a lot of self service apis fully scoped to avoid one MFE messing with others. (I didn’t want to maintain any complex pipeline or more complex management of those MFEs, so we allow our users to do it on their own with our guardrails in place)

### Shared Capabilities

What should goes inside the App Shell? What capabilities should be part of the core framework and what should be done 3rd party.

In most of the open source solutions they already provide some idea on what should be part of the framework and you can just build around of it.

When deciding on a custom solution you need to decide what should be a MFE and what should be a core capability and that can blurry some lines, specially when you’re building a framework and want others to adopt it inside the organization because they would ask you for some capabilities such as Authorization and Authentication (usually SSO) from the framework.

In general even being provided as “core capability” I would say that it is better to make it as its own MFE being maintained by the Framework team.

### One more thing…

In general, the main problem with MFEs are trying to solve isn’t the tech itself, usually the technology is the easiest part of our jobs.

Most techniques were being used for couple of years before we talked about MFEs and we can always simply have good modularity of our code and things would be fine.

The main problem is how to keep sane with a monolith being touched by couple of tens, hundreds or even thousands of developers spread around multiple teams not talking with each other but at the same time maintaining this little monster.

It isn’t impossible without MFEs, but similar as MicroServices it lies on people to fix it.

Splitting the knowledge into smaller domains, embracing automation and autonomy are the pillars that would make a MFE project work, having the teams working on the correct places without need to know the whole app and breaking stuff is easier, but in isolated MFEs it might be simpler to maintain in the longer run.

Again, going into MFEs and starting to create “nano” FEs won’t help much, so try to keep the balance and use the known knowledge for split the domains and creating those projects wisely as we do in MicroServices stuff.

I guess that’s basically it, I didn’t went deeper, but I believe I could made a spark on you to go and learn more about this great topic 🙂

Thank you.


Micro-Frontends are not a new trend anymore, but a reality. In this post I will to share about my experience building my own framework.

Micro Front-Ends Key Takeaways


This weekend, during a weekly meeting of [TáBarato App](https://www.tabaratoapp.com/) an idea came out on how we as a really small team could improve our engagement on social media.

A damn nice idea came out that we could have some more posts with some interesting data that we already have and our users would like to have it on their feed and potentially being interested in download our app.

Let me say it again, we're a damn small team of ambitious engineers with a dream, unfortunately at this stage this isn't our money maker, so because of that, my first idea was to basically automate it.

At the same week, I was reading a post about some great developer experience products and one of them made myself interested [Bannerbear](https://www.bannerbear.com/) which is basically what we're talking about a way to create a simple template where I could input my data and push it to any social network easily.

If you're interested about this Developer Experience or simply DX, I strongly recommend to start at this **[Awesome Developer Experience](https://github.com/workos-inc/awesome-developer-experience)** repository.

The biggest problem with Bannerbear at least on our current stage is the pricing. We initially have a quite simple use case and they have a really awesome bazooka to use, but we're just starting, so no Bannerbear for now 😢.

Then I started my POC for fun.

## Proof of concept

My initial goal in the POC was basically being able to create a template programmatically and inject variables on it in a way that I could put inside some lambda and push forward.

So the end goal of it would be simply generating an image based on a template and an input.

No deployment needed, storage or next steps(although I've in mind how the architecture in the end would looks like… ⚠️ SPOILER ALERT ⚠️ I will share a bit of mine initial idea of the end to end plan of it).

## Planning phase

I had a damn little experience manipulating images, mostly from the time I made my CMS in PHP(which is a shame I lost, so use Git on your project from start) and it was doing some simple manipulations with **[ImageMagic](https://imagemagick.org/index.php)** lib just to reside and store it in the server.

Besides that again another simple use case to generate images dynamically from my Amazon S3 bucket and provide some resizing manipulation in the query string inside AWS CloudFront (this time, using [sharp](https://sharp.pixelplumbing.com/) instead of **[ImageMagic](https://imagemagick.org/index.php)).**

So my initial idea was just to take sharp, and inspired by BannerBear API create a template and process it.

Then before any implementation details I played a bit around how I would like to consume such tool.

After being satisfied with end result, then I moved to the Building phase 😉

## Building phase

Take a look on how my template is supposed to looks like:

```javascript title="generator.js"
const template = {
  stage: {
    width: 1080,
    height: 1080,
    background: { r: 255, g: 0, b: 0, alpha: 1 },
  },
  layers: [
    {
      type: 'box',
      position: [200, 100],
      width: 650,
      height: 250,
      background: 'white',
    },
    {
      type: 'box',
      position: [600, 300],
      width: 650,
      height: 250,
      background: 'white',
    },
    {
      type: 'text',
      position: [220, 120],
      color: 'black',
      input: 'productDescription1',
    },
    {
      type: 'text',
      position: [280, 120],
      color: 'black',
      input: 'productPrice1',
    },
    {
      type: 'image',
      position: [200, 500],
      background: 'transparent',
      width: 240,
      height: 360,
      input: 'productImage1',
    },
    {
      type: 'text',
      position: [620, 320],
      color: 'black',
      input: 'productDescription2',
    },
    {
      type: 'text',
      position: [680, 320],
      color: 'black',
      input: 'productPrice2',
    },
    {
      type: 'image',
      position: [600, 700],
      background: 'transparent',
      width: 240,
      height: 360,
      input: 'productImage2',
    },
  ],
}
```

Then, let me explain a bit on how this template is supposed to work:

### Stage

Stage property sets as the name suggest the stage for the other changes, like when you're starting a new file in Photoshop or Figma, you need to set your stage before beginning.

So, simple as providing the size and initial background color.

### Layers

This is where the magic begins. Every single component should be a layer, so they're arguably independent.

Those layers have types (described below) and the specific properties from those types.

<aside>
💡 As an evolution of it, more complex layers or types could be added in order to group and apply some specific filter or effect only into a set of layers/components .

</aside>

#### Type

I decided to support few simple types of objects inside my image generator, `box`, `background-image`, `image`, `text` and a plan to support some sort of `filter` also, but not today.

So, this property will let me know what kind of strategy I should use to render it.

#### Position

This is quite straightforward one, a simple tuple with `[top, left]` absolute values(px). At some point it can be evolved into relative values as well.

#### Width/Height

No new concept here, those are exactly as the name suggest, it should define size of our component inside the stage.

#### Background

A way to force this layer to have a specific background color. A damn useful in the case of boxes where you want them to have a different background color.

#### Color

Exactly like `box`es, but for `text` type more specifically to set the color of the text.

#### Input

This would define the name of variable which my generator needs to looks after in the variables object.

```javascript title="generator.js"
const variables = [
  { name: 'productDescription1', text: 'Cenoura' },
  { name: 'productPrice1', text: 'R$: 12,59' },
  {
    name: 'productImage1',
    image_url:
      'https://s3.amazonaws.com/my-awesome-bucket/images/product/Cenoura.png',
  },
  { name: 'productDescription2', text: 'Frango Aurora' },
  { name: 'productPrice2', text: 'R$: 6,99' },
  {
    name: 'productImage2',
    image_url:
      'https://s3.amazonaws.com/my-awesome-bucket/images/product/coxa.frango-aurora.png',
  },
]
```

So, this is how my variables looks like and how I would include my custom data to be displayed based on the template.

<aside>
💡 Just pay attention that the property name should match with the property input form the template.

</aside>

### The generator

So, both of our inputs are in place now we must implement a way to transform this code into something that we could possibility think of post into our socials.

![Final result](/static/img/posts/generate-socials/result.png)

The end result should be something like the image above based on the template.

For brevity I won't post the full code here, but mostly the key takeaways of it, if you would be interested into see this code later on, let me know in the comments.

```javascript title="generator.js"
// Merge layers with available variables
function addVariablesToLayers(layers, variables) {}

// Download image when source is a image url.
async downloadImage(url, image_path) {}

// Basically how to process the layer/component to be shown.
async function processX(stage, layer) {}

// main function responsible to glue everything together.
async function generate(template, variables) {}
```

This `processX` is any supported layer type, as how to process and translate the such layer should be treated as a separated strategy to be rendered.

Then in the end of `generate` function you will be ready to glue everything together inside sharp and being happy.

I would be true if I hadn't to deal with SVGs for texts and boxes.

In here, my biggest issue was that I'm not that into SVGs on the stand point of a developer, but more often as a consumer.

<aside>
💡 Initially I  thought about simply using sharp and it's composite image API to being able to work and continue the home chores, but as more as I think about it, I guess better would be to start over only on top of SVGs.

</aside>

```tsx
function processText(stage, layer) {
  const textInput = Buffer.from(`
  <svg xmlns="http://www.w3.org/2000/svg">
    <g>
      ${
        layer.background
          ? `<rect
        fill="${layer.background}"
        stroke="${layer.background}"
        stroke-width="0"
        width="100%"
        height="100%"
        x="0"
        y="0"
      />`
          : ''
      }
      <text
        fill="${layer.color}"
        font-size="64"
        stroke="${layer.color}"
        stroke-width="0"
        x="0"
        y="50"
      >
        ${layer.text}
      </text>
    </g>
  </svg>
  `)

  return {
    input: textInput,
    top: layer.position[0],
    left: layer.position[1],
  }
}
```

So, this is how I do render text at this moment, simply wrap a SVG with `rect` and `text` so we could show some text with nice effect of having a background only for the text.

Basically the SVG and using it to display the text and boxes was the easiest way I found to show such contents at this image, but as I mentioned earlier, I'm more convinced that SVG from scratch should do a nice work here, but today I used only sharp.

```javascript title="generator.js"
export async function generate(template, modifications) {
  const { stage, layers: rawLayers } = template
  const layers = addVariablesToLayers(rawLayers, modifications)

  const layersPromise = layers.map((layer) => {
    switch (layer.type) {
      case 'background-image':
        return processBackground(stage, layer)
      case 'text':
        return processText(stage, layer)
      case 'image':
        return processImage(stage, layer)
      case 'box':
        return processBox(stage, layer)
    }
  })

  const readyLayers = await Promise.all(layersPromise)

  await sharp({
    create: {
      width: stage.width,
      height: stage.height,
      channels: 4,
      background: stage.background,
    },
  })
    .composite(readyLayers)
    .png()
    .toFile('./tmp/result.png')
    .catch(console.error)
}
```

This as simple as how I got it to work and generate the result you saw above also based on the template showed above.

### Challenges

**Visual Appeal**

At this point this generator is damn rustic, although useful for the purpose I made it.

As I mentioned above, dealing with the SVG directly is my main pain point, but it could be overcome after some more deep dive into them.

It would enable me to create much more appealing view of those images.

**Calculating Positions**

For simple use cases this should be ok doing it, but starting with a real generator that we would need not constant, but changes that can happen often, would be better to build a visual builder for the template, even with simple UI, but at least to help with positioning and sizing (preview also) of the layers of the template would be useful and make our life easier.

## Next steps after the POC?

![High level architecture of the system](/static/img/posts/generate-socials/Social_Image_generator_as_a_service.png)

High level architecture of the system

As the proof was basically to show how to generate such images, at this stage I'm satisfied with the result, but of course we need to think about how to continue it.

For now, my main idea is basically trying to find the ~~cheapest~~ most cost effective way of deploying it and 1M executions monthly of AWS Lamba is quite appealing in this area.

Besides that, AWS also offers S3 and DynamoDB on it's free tier which in this case wouldn't require that much of storage, so it's free tier would be more than enough of doing it.

As this is something that we would usually do daily, setting an event (cron job) to everyday to start the image generator using an specific template would be also a possibility.

Lambda itself would just consume our internal API to retrieve the data to put into the template and grab the template from DynamoDB table.

When image is completed, we would basically push it to S3 bucket where after saved, it would dispatch an event to trigger our another lambda which would be responsible to publish the image into our social network of choice.

---

I believe that's all for now. If you missed any detail that I could improve in the code or found any typo or English mistake, let me know and I will be more than happy to fix and improve my writing.

C ya next


Automate social image generation is a real part of our work in some areas. If you had a simple use case, you may find this post a good start

Generate social images as a service


<aside>
💡 Talvez seja apenas um sentimento meu, mas mesmo que seja acho que é um ponto válido a compartilhar.
</aside>

## Conhecendo a casa nova!

Quando entramos em uma empresa nova de desenvolvimento, seja uma startup, uma consultoria, uma software house ou até mesmo grandes corporações, algo que me deixa um pouco intrigado é a falta de documentação para novos desenvolvedores.

Ainda não trabalhei em uma grande corporação, mas reza a lenda que eles tem manuais para tudo até como sentar, e coisas do tipo, não sou de duvidar, burocracia a alma do negócio(em alguns casos).

Mas, a escassez desses manuais torna-se um problema também, uma vez que estamos construindo nosso sistema desde o começo é fácil pegar todas as partes, entender e juntar as mesmas, entretanto, quando o sistema já está no ar, funcionando com diversas regras de negócio complexas e afins é realmente algo bem complicado de se assimilar.

Quando a equipe cresce precisamos ter um mecanismo para que nossos desenvolvedores possam fazer o bootstrap da nossa aplicação da maneira mais simples e rápida para que eles consigam se encontrar no código e produzir algo útil.

## Falar é mais fácil do que entender o código

Como eu fiz o sistema, ou peguei ele desde o começo ou a versão 2.0 onde matamos tudo o que tinha na anterior é tudo muito claro na minha mente. Mesmo que usando as ferramentas mais comuns, cada sistema tem uma peculiaridade que deve constar em algum lugar de fácil acesso a ingressantes na empresa.

> "Existe um arquivo .env de exemplo para que eu possa usar para iniciar o sistema aqui?""Não, nunca pensamos que alguém ia perguntar isso!"

Mesmo que seu sistema use o framework mais usado no mundo, tenho 100% de certeza que ele vai ter alguma peculiaridade única que pode influenciar o bootstrap do mesmo. A não ser que o seu sistema seja apenas um CRUD de exemplo do framework, ai realmente não é preciso documentar nada, apenas indicar a página da documentação do seu framework.

Entretanto, para os outros casos (maioria acredito) ter um README no repositório do código com os primeiros passos para rodar seu sistema, evitaria 90% das perguntas básicas de quando baixamos pela primeira vez o sistema.

```
git clonegit@github.com:thebergamo/start-hapiness.git
```

> "Como eu faço para rodar o projeto? Rodo esse arquivo main? Tem que baixar alguma coisa além do <nome do interpretador/compilador da sua lang>?"

> "Tem que instalar qual banco de dados? Tem usuário padrão setado no código?"

## Business é importante também!

Certo, deixando o código um pouco de lado, vamos falar um pouco sobre o que estamos desenvolvendo também, não apenas o código em si.

Na minha opinião, saber o que estamos desenvolvendo ou por que estamos desenvolvendo e para onde estamos indo ajuda na hora de resolver os problemas que podem ser ocasionados em código.

Entender o produto é algo importante para o desenvolvimento, isso eu aprendi no meu curto período na Pagar.me, não podemos simplesmente sentar o traseiro na cadeira e escrever códigos com um cabresto.

Devemos saber onde estamos trabalhando, o que estamos fazendo para fazer sempre o melhor.

Sabendo o que a feature xpto1 representa no contexto geral da aplicação, dos negócios, por que ela é importante pode mudar completamente como a mesma vai ser implementada, pois "construir uma função que receba um número e devolver outro número derivado" é algo muito abstrato.

Mas, quando sabemos que essa função vai ser parte de uma outra função que vai retornar as _estatísticas de acessos do usuário_ ou algo que seja realmente importante pro futuro, pode dar uma brecha para fazermos uma função genérica que possa ser estendida no futuro já que uma nova função talvez fosse gerada para suprir uma outra necessidade, mas como você sabia que essa necessidade viria, tornou sua função mais extensível para já estar preparada para o que viria no futuro.

## Precisamos ter em vista futuros colegas chegando!

O que quero dizer é que você como desenvolvedor que está iniciando um projeto na sua nova empresa deve ter sempre em mente que sua equipe pode crescer da noite pro dia, dependendo do sucesso da sua empresa, sendo assim você vai tem que estar preparado para não desperdiçar 1 ou 2 meses treinando o novo funcionário em coisas banais do seu sistema, pois poderia investir algum tempo a mais e documentar os processos e as regras de negócios que sua API deveria contemplar, ou pelo menos um resumo.

> "A documentação é meu código, se o cara não entender o que está escrito ali, ele não deve mexer"

E você desenvolvedor que está ingressando na empresa também deveria estar mais preocupado em entender mais sobre o que está fazendo, não apenas sentar e ouvir as ordens e simplesmente fazer.

## Entenda, Pense e Faça!

Pois em algum momento, desenvolvedores que simplesmente escrevem o código sem saber para que estão escrevendo serão substituídos por máquinas, pois podem ser automatizados.

> "Quero alguém que pense, não um robô, escrever código é fácil, desenvolver sistemas é que é complicado"

Somos todos responsáveis por fazer nosso local de trabalho um lugar melhor para nós e para nossos atuais e futuros colegas de trabalho. Gastar um pouco de tempo a mais documentando da maneira mais simples possível um processo pode causar uma economia absurda de tempo quando temos um novo colega para mostrar a casa.

Sempre tenham como espelhos os projetos OpenSource e mantenha a casa bem arrumada, para que quando novos contribuidores apareçam eles se sintam bem acomodados, não no meio de uma zona de guerra!

Obrigado =D


Começar um emprego novo é sempre uma experiência cheia de aprendizados, gostaria de compartilhar o meu sentimento sobre essa nova vivência

Precisamos falar sobre os novos desevolvedores!


I started my Computer Science degree in 2012, just after leaving high school and while being already employed before starting it, because I had been in technical school studying programming back then.

After two years in CS, I realized that it was just “stealing” time from me, all those evenings that I could improve my JavaScript, Java, or any other development skills were lost to studying this Big O notation that I would never need to use in professional life (YET).

So, after realizing it, I dropped the studies and started to use this time to learn “real world” things besides academical ones. It was a really good experience. I spent long weekends playing with Node.js, doing what a friend of mine calls “server-side shit”, It was amazing, I was doing calculus, not coding a boring linked list in Java anymore, I was doing “production ready” code and sharing with the world.

That was a younger version of me, so much energy, lack of sleep and still being productive.

So, as you read these words, you might think that you should drop off your current degree or even don’t start one and follow the same path I did? Maybe that would not be a good idea.

I always advocate that, a CS degree is important for one thing.

> Getting to know that some smart people had already faced few problems in the past that you might suffer from or not, but it’s always good to know that some solutions already exist, and even though you might not have the same problem, you can adapt an existing solution.

You can still learn these things without going to any university, you can find good materials around internet related to open courses and so on. So, just in case I will try to suggest few options to learn. (If I get more suggestions I may update the list)

- [https://github.com/ossu/computer-science](https://github.com/ossu/computer-science)
- [https://www.mooc-list.com/tags/computer-science](https://www.mooc-list.com/tags/computer-science)

So, the important thing to me and what I advocate is, getting to know about concepts, algorithms, some computer theories but not struggling to learn that by heart, just getting conscious why they exist and what problems they can solve.

It’s not bad, reinventing the wheel lots of time, especially while trying to solve the same problems with a different approach, but not starting with an empty page, using some background to your exercise. Finding alternatives, where them fail, where them succeed.

Everybody will tell you that you should “Keep it simple”, but it’s hard to realize how difficult it is to create simple solutions instead of complicated ones. That’s why we have this much of overengineering all the time and creating legacy code from scratch.

There is no book to teach you how to “Keep it simple”, just time and experience, so don’t mind to creating overcomplicated solutions, but be aware about others’ solutions and use them whenever possible.

We live in the information era, good practices are everywhere, lots of useful projects are shared in Github every day, even maybe some might not be that useful, but you can still learn from that.

So, some types of people might not need a degree in computer science to not know these concepts, patterns, theorems and so on, because they look for more information, if you’re one of these people, it’s really great for you, spread your knowledge inside your team, your community, in the world.

Some others might need it because, learning on your own is not that simple (remember that I said that simple, is not that simple?), you might need some guidance, help and then a university or course would you help to improve your knowledge and be **a better professional**.

You might not need a computer science degree, but you might need to know some of concepts presented in these courses in order to become **a better professional**.

Whenever you choose do it, find knowledge wherever is easier for you and spread to others, help others to grow like probably somebody did for you previously or if not just do it anyway, we need more people like you.


For sure you might not need a CS degree, but that does not mean that you shouldn't learn it somehow.

You might not need a computer science degree


## Introdução

Quando ouvi pela primeira vez o termo NoSQL, imaginei logo “Não SQL??” e os questionamentos vieram tão rápido quanto esse pensamento: “Como assim não usar SQL não faz sentido algum isso”, “Não é possível usar um Banco de Dados não relacional” entre outros.

Só que para a minha surpresa alguns meses depois fui conhecendo melhor a tecnologia abordada pelos NoSQL da vida e eles são bem interessantes, mais até do que eu imaginava que pudessem ser.Não sou especialista nessa tecnologia ainda, estou engatinhando nela, entretanto andei lendo alguns artigos e fiquei meio abismado com a modelagem proposta por alguns deles o que me deixou um pouco confuso.

Modelar um banco relacional é algo tão natural hoje que você modela bancos almoçando ou comendo cereal pela manhã. Mas modelar um banco não relacional é algo totalmente diferente pelo menos para mim, ainda fico um pouco com medo de modelar algo assim. Um dos motivos desse “medo” é a aplicação acabar ficando de certa forma inconsistente.

Pode ser que esse seja um pensamento idiota, mas faz algum sentido se parar para pensar que alguns dos NoSQL(como o que eu estou tendo mais contato o MongoDB usarei ele como exemplo) não temos um schema pré definido é o famoso schemaless.

Em algum momento eu posso tentar chamar um determinado dado que só tem em um documento da minha coleção por exemplo. Já te assustei? Eu sabia que não rsrs. No caso o MongoDB oferece alguns recursos para que isso se resolva e você consiga ter dados consistentes nas suas coleções. Não sabe o que é um documento ou uma coleção ??

Certo, fazendo referencia aos Bancos Relacionais, no MongoDB temos as Coleções que são como as Tabelas e os Documentos que são como os registros, basicamente assim. Os registros são armazenados em “documentos” vários documentos se tornam uma coleção e com varias coleções de documentos temos nosso banco =)

Meu Objetivo aqui é apenas demostrar alguns pontos que acho relevantes na abordagem NoSQL, se você leu até aqui e espera que tenham códigos de exemplo abaixo, tenho que lhe informar que não teremos códigos aqui apenas texto corrido sobre minha percepção sobre NoSQL com ênfase no MongoDB. Voltando…Já sabendo o que é uma Coleção e um Documento e sabendo que você não precisa ter toda uma estrutura montada antes de começar a sair codificando ou como gosto de falar “codando”, como eu posso modelar meus dados nesse novo paradigma?

Nos últimos meses passei boa parte do meu tempo pensando em como eu poderia solucionar isso e a solução ainda é confusa pelo menos para mim, caso vocês leitores tenham alguma experiencia com isso mesmo minima peço por gentileza que mandem opiniões de como vocês vem abordando isso.

Mesmo sem saber exatamente como modelar um banco NoSQL algumas coisas vem a minha mente como o que não fazer. Como havia mencionado mais acima vi algumas abordagens onde os autores faziam referencias a outras coleções, sim traduzindo para o nosso mundo SQL eles estavam normalizando o banco NoSQL deles usando as mesmas técnicas que nós usamos no SQL de hoje.

Pelo menos até onde eu entendi a proposta do NoSQL é matar os relacionamentos entre tabelas(no caso coleções) pois foge da proposta do paradigma. Posso estar errado ao pensar assim, mas estamos voltando aos velhos hábitos da modelagem relacional quando fazemos isso não que seja ruim fazer isso, pois funciona bem essa técnica, mas ela tem que ser usada em bancos relacionais pois eles foram feitos para isso.

A partir do momento em que você começa a criar relacionamento entre tabelas em um banco NoSQL você perde totalmente a ideia do paradigma. Pensando por outro lado quando você isso você tem toda a velocidade do MongoDB em uma modelagem que você já usava antes é talvez um MySQL 3.0 (rsrs).

Não defendo essa ideia! A proposta do NoSQL é não depender de relacionamentos, precisa guardar informações de outros dados guarde dentro do seu documento.Pelo menos foi isso que eu entendi, você não tem os velhos problemas de armazenamento que tinhamos há 10 ou 15 anos atrás ou o processamento. Você tem bons processadores e uma Engine fantástica no MongoDB use-a, não tenha medo de ficar replicando dados. A grande pergunta ai para que isso fique bem modelado é: O que pertence ao que?

## Como Modelar

> – Aqui começa o como modelar um NoSQL(MongoDB) –

Segundo minha concepção do NoSQL, antes de qualquer coisa código tenha em mente as entidades que você vai usar, exceto em casos nos quais você está começando agora e não está enraizado nos moldes da Modelagem Relacional você vai primeiro vai pensar na sua solução como relacional.

Se você conseguir modelar um Modelo de Entidade-Relacionamentos(M-ER) você já consegue responder a pergunta “O que pertence ao que?”. Entretanto nem sempre o que pertence ao que no modelo relacional funciona para suas coleções, entretanto você pelo menos vai ter uma ideia de por onde começar. Veja o exemplo a seguir:

No meu blog, digamos que eu resolva parar de preguiça e fazer ele inteiro na mão ao invés de usar wordpress a estrutura do meu Banco caso relacional seria algo assim:

```jsx
User: ID, NAME, USERNAME, PASSWORD
Post: ID, TITLE, CONTENT, SLUG, PUBDATE, ID_USER
Comments: ID, EMAIL, NAME, TEXT, LINK_PHOTO, ID_POST
```

Um Blog básico precisa de pelo menos isso, um Usuário, Postagens e Comentários. Um Usuário realiza uma postagem e uma postagem pode receber vários comentários.Modelando NoSQL você pode pensar de duas formas, uma delas seria você pensar que o Usuário é sua coleção principal e dentro dos seus documentos você vai ter coleções de postagens e dentro de cada documento de postagens você terá uma coleção de comentários.

```json
{
  "_id": "mkdarkness",
  "name": "Marcos",
  "username": "mkdarkness",
  "password": "876tgfde3tyujhgfe43wes",
  "posts": {
    "_id": "go-rountines",
    "title": "Go Routines",
    "content": "Aqui vai o texto da postagem",
    "slug": "go-routines",
    "pubdate": "2014–05–22 10:11:00",
    "comments": [
      {
        "_id": "marcos@thedon.com.br",
        "email": "marcos@thedon.com.br",
        "name": "Marcos",
        "text": "Cara essa postagem é muito boa!",
        "link_photo": "http:cdn.gravatar.com/marcos.jpg",
        "pubdate": "2014–05–23 15:00:00"
      },
      {
        "_id": "marcos2@thedon.com.br",
        "email": "marcos@thedon.com.br",
        "name": "Marcos",
        "text": "Não me canso de ler e comentar!!",
        "link_photo": "http:cdn.gravatar.com/marcos.jpg",
        "pubdate": "2014–05–23 20:00:00"
      }
    ]
  }
}
```

Temos ai nosso começo de banco já modelado ao estilo NoSQL. Uma outra abordagem que eu consigo imaginar é ao invés de estar dentro de usuário poderiamos modelar esse banco em cima da ideia da postagem ser a coleção maior. Nesse caso ainda teriamos que manter a coleção de usuários para autenticações de login, entretanto no caso de usar somente as postagens você pode ter uma coleção de “autores” dentro da postagem onde você apenas irá utilizar as informações do nome ou username do autor ou no caso simplesmente ter uma propriedade “autor” e colocar o nome do usuário que postou ali.

Ficaria assim:

```json
{
  "_id": "go-rountines",
  "title": "Go Routines",
  "content": "Aqui vai o texto da postagem",
  "slug": "go-routines",
  "pubdate": "2014–05–22 10:11:00",
  "comments": [
    {
      "_id": "marcos@thedon.com.br",
      "email": "marcos@thedon.com.br",
      "name": "Marcos",
      "text": "Cara essa postagem é muito boa!",
      "link_photo": "http:cdn.gravatar.com/marcos.jpg",
      "pubdate": "2014–05–23 15:00:00"
    },
    {
      "_id": "marcos2@thedon.com.br",
      "email": "marcos@thedon.com.br",
      "name": "Marcos",
      "text": "Não me canso de ler e comentar!!",
      "link_photo": "http:cdn.gravatar.com/marcos.jpg",
      "pubdate": "2014–05–23 20:00:00"
    }
  ]
}
```

Por que simplesmente não criar uma referencia ali do usuário nessa última coleção ou simplesmente não ter documentos a parte para conter as postagens e só ter uma referencia no documento do usuário ou melhor ainda ter uma coleção só para referencias.

Existem diversas abordagens para esse problema. Todas com vantagens e desvantagens, mas não é o jeito NoSQL de ser. Se for para modelar assim por favor use um MySQL ou PostgreSQL que vai dar na mesma pois nesse caso a velocidade não seria relevante para o carregamento do seu blog.

Se você escolheu um NoSQL modele um NoSQL. Acabei deixando muitas opiniões minhas nessa postagem, mas é para isso que eu fiz esse blog (rsrs).

## Conclusão

Bom, irei falar mais sobre o assunto de NoSQL e MongoDB em outra oportunidade, por hoje meu objetivo foi alcançado.Caso de concordem com o que eu falei deixem um comentário dizendo por que concordam ou simplesmente falem oi =).

Caso discordem por favor deixem comentários também para que eu possa entender melhor esse mundo NoSQL ou rebater um pouco e gerarmos uma discussão saudável onde todos possam se beneficiar com as informações.

Quando ouvi pela primeira vez o termo NoSQL, imaginei logo “Não SQL??” e os questionamentos vieram tão rápido quanto esse pensamento: “Como assim não usar SQL não faz sentido algum isso”, “Não é possível usar um Banco de Dados não relacional” entre outros.

Está foi a minha visão sobre o tema. **Este blog post foi originalmente postado no meu antigo blog que não está mais disponível na internet em 2014. Muita coisa mudou desde então..**


Este blog post foi originalmente postado no meu antigo blog que não está mais disponível na internet em 2014. Muita coisa mudou desde então

Uma visão sobre NoSQL

Eu sou um escritor, na maior parte das vezes, escritor de software, mas já escrevi alguns poemas e contos (nem todos finalizados 😢)

Eu sou Marcos Bérgamo

Software Architect na EPAM Systems

Featured Posts

Create Next.js Open Graph(OG) images at build time

Micro Front-Ends Key Takeaways

Generate social images as a service

Precisamos falar sobre os novos desevolvedores!

You might not need a computer science degree

Uma visão sobre NoSQL