# JobTeaser

JobTeaser's Engineering Team sharing tips and thoughts about programming - Medium

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Stop Defaulting to "use client": A Practical Mental Model for React Server Component Architecture

DevFeed: [Stop Defaulting to "use client": A Practical Mental Model for React Server Component Architecture](<https://devfeed.tech/articles/stop-defaulting-to-use-client-a-practical-mental-model-for-react-server-component-architecture-20101.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/stop-defaulting-to-use-client-a-practical-mental-model-for-react-server-component-architecture-d94dd0a73364?source=rss----bd77d16a0035---4>)

Author: Clarisse Leduc

Published: 2026-04-21T11:14:11Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [React](<https://devfeed.tech/topics/react.md>), [Next.js](<https://devfeed.tech/topics/next-js.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [front-end-development](<https://devfeed.tech/tags/front-end-development.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [next-js](<https://devfeed.tech/tags/next-js.md>), [nextjs](<https://devfeed.tech/tags/nextjs.md>), [react](<https://devfeed.tech/tags/react.md>), [react-server-component](<https://devfeed.tech/tags/react-server-component.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

A practical guide to React Server Component architecture in Next.js. It recommends defaulting to Server Components and using Client Components only where interactivity is required, keeping client boundaries close to interactive elements to reduce shipped JavaScript.

### Source excerpt

How thinking in server-first component boundaries can simplify data flow and reduce client JavaScript in Next.js applications. When I first started working with the Next.js App Router, I kept running into the same situation. Components would suddenly break -- usually after adding a hook or a click handler. The fix felt obvious: add "use client". But after doing this a few times, I realised something: I was slowly turning my application back into a traditional client-side React app. Which defeats the whole point of React Server Components. The real challenge isn't learning how to use Client and Server Components. It's learning how to decide where code should run. Once that mental model clicked, structuring Next.js applications became much clearer -- and often more performant. The Mental Model React Server Components introduce a simple but powerful separation of responsibilities. A helpful rule of thumb: Default to Server Components. Use Client Components only when interactivity is required. Think of it like this: This small shift in thinking has a big impact on how you design component trees. A Simple Example Consider a typical product page. export default async function ProductPage({ params }) { const product = await getProduct(params.id, { cache: "no-store" }) if (!product) { notFound() // Next.js helper for 404 pages } return ( <> <ProductDetails product={product} /> <AddToCartButton productId={product.id} /> </> ) } Here: ProductPage -> Server Component ProductDetails -> Server Component AddToCartButton -> Client Component Only the interactive part runs in the browser. Everything else stays on the server, meaning less JavaScript shipped to the user. The "use client" Boundary One subtle detail that often surprises developers is that "use client" creates a boundary in the component tree. If a component is marked as a Client Component, all of its children become Client Components too. Example: "use client" export default function Page() { return ( <Layout> <ProductInfo /

## Conduct a technical migration within less than 6 months -- Part 3 (final)

DevFeed: [Conduct a technical migration within less than 6 months -- Part 3 (final)](<https://devfeed.tech/articles/conduct-a-technical-migration-within-less-than-6-months-part-3-final-20095.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/conduct-a-technical-migration-within-less-than-6-months-part-3-final-7968c007f770?source=rss----bd77d16a0035---4>)

Author: Fabien RAYNAUD

Published: 2024-12-02T09:47:16Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [migration](<https://devfeed.tech/topics/migration.md>), [Next.js](<https://devfeed.tech/topics/next-js.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [maintenance](<https://devfeed.tech/topics/maintenance.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [migration](<https://devfeed.tech/tags/migration.md>), [next-js](<https://devfeed.tech/tags/next-js.md>), [nextjs](<https://devfeed.tech/tags/nextjs.md>), [project-management](<https://devfeed.tech/tags/project-management.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

### AI overview

The final part of a three-part article about conducting a technical migration at JobTeaser, based on the author's experience with a Next.js migration. It focuses on preparing the organization, organizing the project, preserving developer experience, maintaining automation and documentation, and training the team.

### Source excerpt

Conduct a technical migration within less than 6 months -- Part 3 (final)based on Next.js migration, performed at JobTeaser What is this 3-parts article about: sharing my own experience with handling a technical migration 📖 some additional elements that I find relevant and could help (identified with 📖 emoji) but not personally tested What this presentation is NOT about: technical step-by-step Next.js migration the perfect and only way to do a migration I tried to be as exhaustive as possible, but I didn't even complete all the points personally. So the presentation is a mix of my personal experience and all the things that could help to do it "qualitatively". Pick what is necessary for you and your ecosystem. 3 main parts: Buying time and sponsorship to be able to perform such a migration = creating a good environment to navigate easily to success Organize your project = keep an eye on and communicate about what was done and what needs to be done ▶ Preserve the developer experience = ensure use, sustainability, and future maintenance of the migration You are now ready to focus on the implementation but do not hesitate to make a step aside and check if the learning curve is not too big for newcomers on the migrated part. Preserve the Developer's Experience Finally, it is important to preserve the Developer's Experience throughout the migration process. This means minimizing disruption to the development environment and ensuring that developers can continue to work efficiently. It also means preparing the next step of the project (outside migration) and making it efficient as soon as possible. Analyze and preserve the current development environment of the team Check the used tools and the compatibility after the migration, and communicate if you need to remove one Keep automation as much as possible, nobody wants to get back to manual stuff after a migration Take time to document (update) what you are keeping, newcomers would thank you for that Train the team to be

## Conduct a technical migration within less than 6 months -- Part 2

DevFeed: [Conduct a technical migration within less than 6 months -- Part 2](<https://devfeed.tech/articles/conduct-a-technical-migration-within-less-than-6-months-part-2-20094.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/conduct-a-technical-migration-within-less-than-6-months-part-2-c4f2cd1feea4?source=rss----bd77d16a0035---4>)

Author: Fabien RAYNAUD

Published: 2024-12-02T09:46:56Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [migration](<https://devfeed.tech/topics/migration.md>), [Next.js](<https://devfeed.tech/topics/next-js.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [maintenance](<https://devfeed.tech/topics/maintenance.md>)

Tags: [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [migration](<https://devfeed.tech/tags/migration.md>), [next-js](<https://devfeed.tech/tags/next-js.md>), [nextjs](<https://devfeed.tech/tags/nextjs.md>), [project-management](<https://devfeed.tech/tags/project-management.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

### AI overview

Part 2 of a three-part article about conducting a Next.js technical migration at JobTeaser. It focuses on organizing the migration project by defining a realistic MVP scope, prioritizing tasks, assigning work, communicating progress, and setting deadlines.

### Source excerpt

Conduct a technical migration within less than 6 months -- Part 2based on Next.js migration, performed at JobTeaser What is this 3-parts article about: sharing my own experience with handling a technical migration 📖 some additional elements that I find relevant and could help (identified with 📖 emoji) but not personally tested What this presentation is NOT about: technical step-by-step Next.js migration the perfect and only way to do a migration I tried to be as exhaustive as possible, but I didn't even complete all the points personally. So the presentation is a mix of my personal experience and all the things that could help to do it "qualitatively". Pick what is necessary for you and your ecosystem. 3 main parts: Buying time and sponsorship to be able to perform such a migration = creating a good environment to navigate easily to success ▶ Organize your project = keep an eye on and communicate about what was done and what needs to be done Preserve the developer experience = ensure use, sustainability, and future maintenance of the migration Now that you have convinced the right people and made a big-picture plan, time to jump into the project, whether you are part of the implementation team or not. Organize your project The second step is to organize the project. This includes cleaning the scope of the migration regarding the most important tasks and secondary ones that could be done later. It's also about having a clean place to organize, prioritize, and communicate the project execution. Define the "real" scope of the migration = MVP with only the mandatory tasks: Be prepared for the next steps. You won't be able to perform all the tasks from the initial plan by yourself or with the initial team, only the most important ones Listing and specifying secondary tasks is important for the next steps of the project (after the migration) Continue your technical watch on the subject and adjust the migration if necessary, nobody wants an already deprecated solution. A

## Conduct a technical migration within less than 6 months -- Part 1

DevFeed: [Conduct a technical migration within less than 6 months -- Part 1](<https://devfeed.tech/articles/conduct-a-technical-migration-within-less-than-6-months-part-1-20093.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/conduct-a-technical-migration-within-less-than-6-months-part-1-c1215057a515?source=rss----bd77d16a0035---4>)

Author: Fabien RAYNAUD

Published: 2024-12-02T09:46:26Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [migration](<https://devfeed.tech/topics/migration.md>), [Next.js](<https://devfeed.tech/topics/next-js.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [Front end](<https://devfeed.tech/topics/frontend.md>)

Tags: [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [migration](<https://devfeed.tech/tags/migration.md>), [next-js](<https://devfeed.tech/tags/next-js.md>), [nextjs](<https://devfeed.tech/tags/nextjs.md>), [project-management](<https://devfeed.tech/tags/project-management.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [technical](<https://devfeed.tech/tags/technical.md>)

### AI overview

Part 1 of a three-part article shares a personal experience conducting a technical migration to Next.js at JobTeaser. It covers securing sponsorship and time, organizing the project, preserving developer experience, and a timeline involving an audit, production ecosystem, and first use case.

### Source excerpt

Conduct a technical migration within less than 6 months -- Part 1based on Next.js migration, performed at JobTeaser What is this 3-parts article about: sharing my own experience with handling a technical migration 📖 some additional elements that I find relevant and could help (identified with 📖 emoji) but not personally tested What this presentation is NOT about: technical step-by-step Next.js migration the perfect and only way to do a migration I tried to be as exhaustive as possible, but I didn't even complete all the points personally. So the presentation is a mix of my personal experience and all the things that could help to do it "qualitatively". Pick what is necessary for you and your ecosystem. 3 main parts: ▶ Buying time and sponsorship to be able to perform such a migration = creating a good environment to navigate easily to success Organize your project = keep an eye on and communicate about what was done and what needs to be done Preserve the developer experience = ensure use, sustainability, and future maintenance of the migration Timeline of the migration 🔍 Concrete "real life" timing 2 weeks to build an audit in August, done in autonomy and presented to frontend chapter, management, and tech leadership 3 months to put a minimalist ecosystem into production, from November to January, done mainly in autonomy with the help of the Devex and Infra team, and also from hyped frontend engineers 2 months for the release of the first "real life" use case, from February to March, by a squad of 3 engineers + 2 others squads starting their own features on the new stack Buying time and sponsorship to do the migration The first step is buying time and sponsorship for the migration. This is essential to ensure that the necessary resources and funding will be available for the initiative, aka the right environment, to perform the migration properly. This part is more about digging into the pros and cons of this migration and being able to explain it so people will ack

## How to Audit and Organize CSS z-index Values and Stacking Contexts

DevFeed: [How to Audit and Organize CSS z-index Values and Stacking Contexts](<https://devfeed.tech/articles/spring-cleaning-for-z-indexes-20100.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/spring-cleaning-for-z-indexes-42beba8e526a?source=rss----bd77d16a0035---4>)

Author: Jean-Jacques Royneau

Published: 2024-11-05T10:06:48Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [CSS](<https://devfeed.tech/topics/css.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [modern web development](<https://devfeed.tech/topics/modern-web-development.md>)

Tags: [audit](<https://devfeed.tech/tags/audit.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [cleanup](<https://devfeed.tech/tags/cleanup.md>), [css](<https://devfeed.tech/tags/css.md>), [display](<https://devfeed.tech/tags/display.md>), [properties](<https://devfeed.tech/tags/properties.md>), [stacking-context](<https://devfeed.tech/tags/stacking-context.md>), [z-index](<https://devfeed.tech/tags/z-index.md>)

### AI overview

This article describes auditing z-index declarations, centralizing values with CSS custom properties, and reducing unnecessary z-indexes by accounting for stacking contexts and natural DOM order.

### Source excerpt

Managing z-index is a classic challenge for front-end developers. As a project grows, display conflicts and bugs related to z-index can quickly turn into serious headaches. I recently took some time to clean up the z-indexes in one of our projects. In this article, I'll share the approach I used for this cleanup (while also laying the foundation for keeping things manageable in the long run). 1. Analyzing the existing z-indexes The first step was to perform a thorough audit of all the z-index declarations in the project. This gave me an overview of how many z-indexes we had and what values were being used. Here's what I found: - August 2023: 57 declarations with 8 distinct values. - February 2024: 87 declarations with 19 distinct values. This evolution showed me that the use of z-indexes had increased significantly. And there was no reason to believe it would stop. With that in mind, my goal became to centralize and standardize these values. 2. Centralizing z-indexes with CSS Custom Properties I centralized all the z-index values in a single file using CSS custom properties. This allowed me to have an overview of the different layers of elements on the page, helping me get a (slightly) clearer picture of the task ahead. If you'd like to get an idea (or maybe scare yourself a bit), here's what that first file looked like: :root { - z-index-second-basement: -2; - z-index-basement: -1; - z-index-ground: 0; - z-index-floor: 1; - z-index-second-floor: 2; - z-index-third-floor: 3; - z-index-job-ads-secondary-filters--selects: 10; - z-index-job-ads-results-sort: 10; - z-index-job-ads-primary-filters: 20; - z-index-fo-header: 30; - z-index-above-fo-header: 31; - z-index-fo-header--dropdowns: 100; - z-index-career-center--login-modal--autocomplete-list: 99; - z-index-bo-drawer-backdrop: 999; - z-index-bo-drawer: 1000; - z-index-feature-env-switcher: 9999; - z-index-notifications-panel: 10000; - z-index-msw-tools-panel--open-button: 99999; - z-index-msw-tools-panel: 999999; }

## Making sense of TypeScript generics

DevFeed: [Making sense of TypeScript generics](<https://devfeed.tech/articles/making-sense-of-typescript-generics-20098.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/making-sense-of-typescript-generics-6b830e66eeff?source=rss----bd77d16a0035---4>)

Author: Clément Gateaud

Published: 2024-07-04T16:12:05Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [TypeScript](<https://devfeed.tech/topics/typescript.md>), [generics](<https://devfeed.tech/topics/generics.md>), [Code](<https://devfeed.tech/topics/code.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [errors](<https://devfeed.tech/tags/errors.md>), [generics](<https://devfeed.tech/tags/generics.md>), [generics-in-typescript](<https://devfeed.tech/tags/generics-in-typescript.md>), [type-parameter](<https://devfeed.tech/tags/type-parameter.md>), [type-safety](<https://devfeed.tech/tags/type-safety.md>), [types](<https://devfeed.tech/tags/types.md>), [typescript](<https://devfeed.tech/tags/typescript.md>), [web-development](<https://devfeed.tech/tags/web-development.md>)

### AI overview

This tutorial explains TypeScript generics through a simple JavaScript function that returns the first element of an array. It contrasts generics with using any, explicit lists of possible types, and type assertions, emphasizing improved type inference and type safety.

### Source excerpt

TypeScript significantly improved JavaScript development with enhanced code reliability and maintainability, ensuring fewer runtime errors and greater productivity for developers. But when you start working with it, the syntax can sometimes feel overwhelming. One of the most intimidating features in TypeScript is "generics". Look at the example below 🤯 aren't you afraid ? Types declarations from @tanstack/react-query (library) that can feel overwhelming But don't worry, we will go step by step and once you understand generics, you'll see how powerful they are. The best any alternative Imagine this very simple JavaScript function that returns the first element of an array. (I agree, this function is not very useful, but it's for the sake of explanation). How could we type it? 🤔 What would be the type of the array? Well, in this function it could be an array of anything (a string, a number, an object). So it could be tempting to type it like this, using the type whose name must not be spoken: any 😱 But this is very bad typing. Why? Because TypeScript won't be able to properly infer the return type of this function. So maybe we could specify all the different types it could be? Not a good idea. First, because it would force you to maintain a huge list of all the possible types for this function. But more importantly, because it doesn't solve our inference issue. TypeScript is not smart enough to guess the type when calling the function. So maybe we could use casting with as to help TypeScript? But that's cheating! With this type assertion, you are telling TypeScript: "Stop type checking and trust me, I know what I'm doing". This weakens type safety which is the core purpose of using TypeScript. Don't do that! There's a way safer and cleaner way to type this. Guess how it's named? ✨ Generics✨ Introducing generics Let's keep our previous example. What we want to tell our function is: "You will take as a parameter an array of SOMETHING, and you will return a SOMETHING ele

## Seven Tips for Junior Developers

DevFeed: [Seven Tips for Junior Developers](<https://devfeed.tech/articles/7-tips-to-survive-as-a-junior-developer-20092.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/7-tips-to-survive-as-a-junior-developer-b15b47586fb4?source=rss----bd77d16a0035---4>)

Author: Clément Gateaud

Published: 2023-05-23T14:06:01Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [coding](<https://devfeed.tech/topics/coding.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [careers](<https://devfeed.tech/tags/careers.md>), [code](<https://devfeed.tech/tags/code.md>), [developer](<https://devfeed.tech/tags/developer.md>), [junior](<https://devfeed.tech/tags/junior.md>), [junior-developer](<https://devfeed.tech/tags/junior-developer.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [tips](<https://devfeed.tech/tags/tips.md>)

### AI overview

A career-advice article for junior developers. It recommends focusing first on the code needed for the current task, attempting to work through problems before seeking help, and using web resources to investigate issues.

### Source excerpt

© Midjourney Whether you're fresh out of school or transitioning from another career, landing a job as a junior developer is a great accomplishment. But it's only the first step on your path to a successful career. Finding your marks in this new position is the next big challenge. In this article I'll share with you 7 tips I would have loved to receive when I started as a junior developer, one year ago. 1. Learn to walk before you run During your first days as a "professional" developer, you will most likely feel overwhelmed by the size and complexity of your company's codebase. "What are all those files? Do we really need millions of lines of code to run our application?". It will for sure look very different from the small side projects you've worked on so far. Don't bother trying to understand the whole codebase and how everything is structured. Just focus on what you need for your current task. If your first task involves a minor fix to a specific behavior, focus on the file that's responsible for that behavior and forget about the rest. It's already a significant challenge to understand the necessary code for your initial task, especially since you'll also be learning about the company's processes, people, and products. https://medium.com/media/12a11f60dbd4c74090fdadd0e0f0fded/href Don't get me wrong, getting a bigger picture is important, but take it one step at a time. You will get more comfortable with the rest of the codebase over time. If you try to assimilate everything, you will assimilate nothing. Choose your fights. Time will do the rest. 2. Getting stuck is great (but not for too long) You'll get stuck on some issues when coding (just like every developer in the history of mankind). It may sound counterintuitive but getting stuck is a chance. Why? Because it is in those situations that you'll learn the most. https://medium.com/media/2776dac640fcf556b334de07293fd1e4/href Do not ask for help right away. Do your best to understand how things work and try

## Data replication across backend services with Kafka and Protobuf

DevFeed: [Data replication across backend services with Kafka and Protobuf](<https://devfeed.tech/articles/data-replication-across-backend-services-with-kafka-and-protobuf-20096.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/data-replication-across-backend-services-with-kafka-and-protobuf-cad1d9fd9f90?source=rss----bd77d16a0035---4>)

Author: Emmanuel Joubaud

Published: 2023-04-14T10:01:57Z

Content type: tutorial

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [Back end](<https://devfeed.tech/topics/backend.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [data-architecture](<https://devfeed.tech/topics/data-architecture.md>), [API](<https://devfeed.tech/topics/api.md>), [Structured-data](<https://devfeed.tech/topics/structured-data.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [backend](<https://devfeed.tech/tags/backend.md>), [data](<https://devfeed.tech/tags/data.md>), [data-replication](<https://devfeed.tech/tags/data-replication.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [replication](<https://devfeed.tech/tags/replication.md>), [serialization](<https://devfeed.tech/tags/serialization.md>), [serialization-format](<https://devfeed.tech/tags/serialization-format.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

This tutorial explains Jobteaser's Silos architecture for replicating data across backend services. It describes using Kafka topics and Google Protobuf messages so consumer services can maintain local database copies while avoiding synchronous service-to-service API calls.

### Source excerpt

The Jobteaser application contains a lot of different relatively independent modules to help universities provide career guidance to students: a job board, a career event management system, a career advice appointment management system... When we decided to migrate our application's backend from a monolith to a service-oriented architecture, we strived to keep each module as isolated as possible from the others in the event of an incident. If the career appointment system was down, students should still be able to browse and apply to job ads. That isolation is achieved through what we've called our Silos architecture. The gist is we avoid synchronous API calls between backend services, and prefer asynchronous data integration between services. There are a lot of different ways to implement asynchronous communication between services, and few companies share the details of theirs so we had to figure out a lot of stuff on our own. Now that we've refined our system, we thought we'd share the details of our approach, based on simple data replication using Kafka and Protobuf. How it worksWhen a write operation happens, data is changed first on the Source of Truth service, who then publishes it to a Kafka topic that consumers can subscribe to, in order to replicate their own local copy in their databaseSource of Truth and consumers Every table in our data model has an owner service, also called the Source of Truth (SoT) for that data, or the producer. For instance, the job board service may be the SoT for the job ad data. The owner service has 3 main responsibilities: it receives and validates all write requests for the data it owns (Create, Update, Delete) it stores the data to its own database, i.e. the Source of Truth, the authoritative state of the data if it's data that other services might want to access, it publishes its latest state as a message into a Kafka topic Consumer services that are interested in accessing a given table can then subscribe to the Kafka topic

## Layers vs Silos, a tale of 2 microservice architectures

DevFeed: [Layers vs Silos, a tale of 2 microservice architectures](<https://devfeed.tech/articles/layers-vs-silos-a-tale-of-2-microservice-architectures-20097.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/layers-vs-silos-a-tale-of-2-microservice-architectures-50c21016e9b1?source=rss----bd77d16a0035---4>)

Author: Emmanuel Joubaud

Published: 2023-04-07T10:01:02Z

Content type: article

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [Microservices](<https://devfeed.tech/topics/microservices.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [API](<https://devfeed.tech/topics/api.md>), [event driven](<https://devfeed.tech/topics/event-driven.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [database](<https://devfeed.tech/tags/database.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [go](<https://devfeed.tech/tags/go.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [replication](<https://devfeed.tech/tags/replication.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

This article compares two extreme communication patterns for microservices: synchronous API calls, which tend to create layered dependencies, and asynchronous event-driven communication or data replication, which tends to create more independent silos. It presents these patterns as a spectrum and discusses trade-offs in business and composition layers.

### Source excerpt

When it comes to the communication between microservices, there are 2 possible extremes: All-sync: whenever a service needs data from another service, it fetches it via a synchronous API call (REST, gRPC, GraphQL). Service calls service calls service... which tends to evolve into layers of APIs, where each layer has dependencies on the next. All-async: no sync calls between services, all communication is event-driven or in the form of data replication. This tends to form silos: independent services that are fed all the data they need by an async mechanism and can function independently of any other service's availability. Of course real-world systems rarely fit either of these 2 extremes perfectly. But whether you plan for it or not, you'll probably end up with a dominant mode or, worse, a random mix. Imagining a spectrum between these 2 extremes can offer a helpful mental model to design a more deliberate architecture, where you control the set of circumstances under which you tend towards one or the other, and the associated trade-offs. LayersAn exemple of layers architecture, for a Career Service Management SystemBusiness layer So you've started building a bunch of business services for your microservice application. They implement business logic and store data. For isolation, you chose to go database-per-service: each service stores a bunch of business objects for which it is the Source of Truth. If you opt for sync-only communications between your services, that means any time one service needs to read another's data, it has to make a synchronous API request to the Source of Truth service, introducing a dependency between them. And if you map those dependencies on a graph, you'll likely notice that software systems tend to contain a few business objects that are depended on way more than others. They're the core of the dependency graph. Often they're your users, your referential data (categories), the items of your e-commerce site, etc. So even within your "busin

## Our microservice stack

DevFeed: [Our microservice stack](<https://devfeed.tech/articles/our-microservice-stack-20099.md>)

Original publisher: [Read original article](<https://medium.com/jobteaser-dev-team/our-microservice-stack-db50aa2b17d6?source=rss----bd77d16a0035---4>)

Author: Emmanuel Joubaud

Published: 2023-03-31T10:34:09Z

Content type: article

Language: en

Sources: [JobTeaser](<https://devfeed.tech/sources/jobteaser.md>)

Topics: [Microservice](<https://devfeed.tech/topics/microservice.md>), [gRPC](<https://devfeed.tech/topics/grpc.md>), [Kafka](<https://devfeed.tech/topics/kafka.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>)

Tags: [go](<https://devfeed.tech/tags/go.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

Jobteaser describes its microservice implementation, including Ruby and Go service chassis, gRPC APIs, Kafka-based data replication, and Kubernetes deployment.

### Source excerpt

This is an introduction to how we've implemented microservices at a mid-size scale-up called Jobteaser, with a mix of Go and Ruby service chassis, gRPC APIs and data replication via Kafka. Foundation: The service chassis Back in early 2019, when Jobteaser decided to get serious about breaking up its decade-old Rails monolith into microservices, we assembled a Foundation team that started working on an in-house service chassis. It was soberly coined service and came in two flavours: the rb-service framework in Ruby and the go-service framework in Go. Four years later, they still form the foundation of our fleet of about 20 services. They provide a lean set of consistent features across the Ruby and Go flavours: a gRPC server component to power our gRPC APIs (more below) a Kafka consumer, to consume messages from a Kafka message queue a Prometheus exporter, to expose monitoring metrics a low-level lib (no ORM) to interact with Postgres, that would be the default database of each service, and optionally Redis for services who require one consistent logging, metrics and error reporting for those components a bunch of CircleCI, Dockerfiles and Kubernetes (k8s) config files to enable automatic deployment in staging and production an executable to start the service a generator script, to scaffold a new service's Walking Skeleton with all of the above and get it deployed to prod in less than a day For a while, the various workloads would all run as threads inside a single process: each instance of a service would run a thread pool for its gRPC server, one for its Kafka consumers, one for its Prometheus exporter, one for its background jobs, etc. That was great for the local dev environment because you didn't need to run a different Docker image for each workload, but we quickly came to split the types of workloads into different pods in production, to avoid issues where a buggy background job could take down the API. Cloud-native Infrastructure All our services are containe