DEV Community: Ruben Marcus

Automating entire workflows with ralph-starter

Ruben Marcus — Thu, 19 Feb 2026 00:52:59 +0000

What is ralph-starter

ralph-starter is a CLI tool that orchestrates AI coding agents in autonomous loops. You give it a task (or point it at a GitHub issue, a Linear ticket, a Notion page), it runs the agent, checks if tests pass, if lint is clean, if build works. If something fails it feeds the error back to the agent and loops again. When everything passes it commits, pushes, and opens a PR.

It supports Claude Code, Cursor, Codex CLI, OpenCode, Gemini CLI, Copilot, Amp, and Openclaw. You do not need to pick one in advance, it auto-detects what you have installed.

It is open source, MIT licensed. I built it because I was tired of being the middleman between my terminal and my AI chat window.

Why I built it

I was using AI coding assistants every day. Claude, ChatGPT, Copilot, whatever was available. And the workflow was always the same: I read a ticket, I open the editor, I start coding, I get stuck, I open the AI chat, I paste the context, I get a suggestion, I adapt it, I paste it back. Then I run tests. Something breaks. I go back to the chat, paste the error, get a fix, paste that back. Lint complains. Another round trip. Then I commit, push, open a PR.

That is like 12 steps and I was doing it 5 to 8 times a day. The AI was doing the hard part (writing the code) and I was just the relay moving text between windows. I felt like a human clipboard.

So I wrote a script that does the relay for me. The script takes a spec, sends it to the agent, runs my test suite, and if something fails it sends the error output back to the agent automatically. No copying, no pasting, no switching windows. The agent sees the error and fixes it on its own.

That script grew into ralph-starter.

Where it is most useful

ralph-starter works best when you have:

A clear spec. "Add /health endpoint that returns 200 with JSON body { status: 'ok' }" finishes in 1 loop. "Make the app better" will still run — the agent will analyze your codebase and pick something to improve — but it might take 4 loops and the result might not be what you wanted. The more specific the spec, the fewer loops and the better the output.
Tests. The loop needs something to validate against. If you have no tests the agent does not know when it is done.
Routine implementation work. Endpoints, bug fixes, component updates, adding tests, config changes. The stuff that fills up a sprint backlog.

Vague specs do not break it, they just cost more. "Refactor the auth system" with no details will make the agent try different approaches each loop until the circuit breaker trips. "Add JWT middleware at src/middleware/auth.ts using bcrypt, httpOnly cookies, add tests for login success and failure" finishes in 2 loops because the agent knows exactly what done looks like.

I use it every day for the mechanical parts of development. I still do the thinking, the architecture, the spec writing. ralph-starter handles the translation from spec to code.

Getting started

You can start from an idea and ralph-starter will generate the spec for you:

Or you can point it at an existing GitHub issue or Linear ticket and it fetches the spec automatically.

# Install and initialize
npx ralph-starter init

ralph-starter init detects your project type (Node.js, Python, Rust, Go), finds which agents you have installed, and sets up your validation commands (test, lint, build). If it finds a Ralph Playbook in your project it picks up AGENTS.md, IMPLEMENTATION_PLAN.md, and your prompt files automatically:

Run your first task with an inline spec:

ralph-starter run "add a /ping endpoint that returns pong" --commit

Or point it at a GitHub issue or Linear ticket:

# From GitHub
ralph-starter run --from github --project rubenmarcus/ralph-starter --issue 2

# From Linear
ralph-starter run --from linear --project ENG --issue ENG-71 --commit --pr

To connect GitHub, Linear, Notion, or Figma as spec sources, use the config commands:

ralph-starter config set github.token ghp_xxx
ralph-starter config set linear.apiKey lin_api_xxx
ralph-starter config set notion.apiKey ntn_xxx

ralph-starter setup configures the CLI agent preferences. Integrations are managed through ralph-starter config.

How the loop works

The loop executor follows this sequence:

1. Fetch spec (GitHub issue, Linear ticket, inline text)
2. Create branch (auto/42-health-endpoint)
3. Run agent with the spec as prompt
4. Run validations: test → lint → build
5. If any validation fails → feed error output back to agent → go to step 3
6. If all pass → commit, push, open PR

The validation step is configurable in ralph-starter.config.yaml:

validation:
  test: pnpm test
  lint: pnpm lint
  build: pnpm build

When a validation fails, ralph-starter takes the stderr/stdout and builds context for the next iteration. The context includes the original spec, the diff of what changed, and the full validation output. The agent sees TypeError: Cannot read property 'id' of undefined at src/routes/user.ts:42 and knows exactly what to fix.

The agent does not get a summary. It gets the raw error. This is faster than me copying the error into a chat window because there is zero delay between failure and the next attempt.

Real example: building a landing page from a GitHub issue

Here is a real run. I pointed ralph-starter at a GitHub issue that asked for a landing page for a London pet shop. The spec had 8 tasks (header, hero, services, gallery, testimonials, contact form, footer, polish).

ralph-starter detected 28 installed skills (frontend-design, tailwind, responsive-web-design, etc.), picked the relevant ones for the task, and started the loop with Claude Code:

The loop ran for 2 iterations. First iteration completed 5 out of 8 tasks (Project Setup, Header & Navigation, Hero Section, Services Section, Featured Pets Gallery). Second iteration picked up the remaining tasks (Testimonials, Contact Form, Footer, Polish). It stopped automatically when no file changes were detected for 2 consecutive iterations.

Final result:

Cost Summary:
  Tokens: 47.0K (764 in / 46.2K out)
  Cost: $0.606 ($0.348/iteration avg)

Loop completed!
  Exit reason: completed
  Iterations: 2
  Total duration: 8m 19s
  Total cost: $0.696 (47.0K tokens)

8 minutes. 69 cents. A full landing page with React components, Tailwind styling, and responsive layout. I did not open the editor at all.

Token costs and how to keep them low

This is something people always ask me about. Here are my real numbers.

I tracked my entire January. 187 tasks completed. $22.41 total. Average of $0.12 per task.

The reason it is cheap is prompt caching. When using Claude Code, the first loop sends the full context at $3.00 per million input tokens. But loops 2, 3, 4 reuse the cached tokens at $0.30 per million. That is 90% less.

Before each run, ralph-starter shows you an estimate so you know what to expect:

After each run it shows the actual cost breakdown: tokens in, tokens out, cache hits, cost per iteration. No surprises. You always know what you are spending.

Most tasks finish in 2 to 3 loops. After the first loop, most of the input is already cached. I wrote the detailed breakdown with exact numbers here.

A few things that help keep costs down:

Good specs mean fewer loops. Clear acceptance criteria = agent knows when it is done.
Prompt caching saves 90% on input tokens after the first loop.
Circuit breaker stops tasks that are stuck, so you do not burn money on something unsolvable.
Skills teach the agent patterns so it gets things right faster (fewer iterations = less cost).

Batch mode: 10 issues, 8 PRs

During sprint grooming I label issues as "auto-ready". These are the well defined tickets with clear specs. Then I run a single command and go get lunch:

ralph-starter picks up all matching issues, shows the estimate for each, and starts the Ralph Wiggum loop one by one:

# From GitHub
ralph-starter auto --source github --project multivmlabs/ralph-starter --label "auto-ready" --limit 10

# From Linear
ralph-starter auto --source linear --project ENG --label "auto-ready" --limit 10

It works with both GitHub Issues and Linear tickets. Each issue gets its own branch, its own loop, its own PR:

[1/10] Issue #145: Add health check endpoint
  > Branch: auto/145
  > 2 loops > Validation: passed
  > PR #151 created

[2/10] Issue #147: Add rate limit headers
  > Branch: auto/147
  > 1 loop > Validation: passed
  > PR #152 created

[3/10] Issue #150: Improve performance
  > 3 loops > Circuit breaker tripped. Skipping.

...

Completed: 8/10 | Failed: 2/10
Total cost: $1.84

8 out of 10. The 2 that failed were vague tickets. One was "Improve performance" with no metrics or targets. The agent tried different optimizations each loop but had nothing to validate against. The circuit breaker tripped after 3 loops.

The other was a refactoring ticket that referenced a discussion from a team meeting. The agent did not have that context.

The circuit breaker trips after 3 consecutive identical failures or 5 of the same error type. It prevents burning tokens on something the agent cannot solve.

Picking an agent

You can be explicit about which agent to use:

ralph-starter run "your task" --agent claude-code
ralph-starter run "your task" --agent codex
ralph-starter run "your task" --agent cursor

Or let ralph-starter auto-detect. It checks what you have installed and uses the first one it finds.

I use Claude Code daily because prompt caching makes the loops cheaper and stream-json output lets ralph-starter track progress in real time. But the loop executor and validation pipeline are the same for all agents. I ran the same JWT auth task on 4 different agents and they all got there, just with different loop counts and costs.

Why I keep building it

I did a side-by-side comparison of 12 tasks from the same sprint. 6 manual, 6 with ralph-starter. Same project, same type of work. The ralph-starter tasks averaged 12 minutes of my attention vs 45 minutes coding manually. Code quality was comparable.

Now I spend my time on three things: writing clear specs (the input), reviewing PRs (the output), and architecture decisions (the part the AI cannot do). Everything in between, the mechanical translation of spec to code, ralph-starter handles that.

Every PR it produces passes tests, lint, and build. Every one. When I code manually I sometimes skip tests for small changes. The validation loop does not let the agent skip anything and honestly that discipline is better than what I do on my own.

About the name

The name comes from the Ralph Wiggum technique. You give the AI a task and let it keep going until done. No micro-managing. Full explanation here.

Links

ralph-starter is open source, MIT licensed.

If you try it, open an issue or drop a star. All feedback is welcome.

Getting started with Next.js + Strapi: Security first

Ruben Marcus — Sun, 16 May 2021 15:03:00 +0000

Why worry about Security?

Before starting to see about Strapi's Content-Types, before looking at Next.js' file and route structure, it's good to discuss Security.

A concern that usually is not followed up with due attention in certain teams, and that can cause a very high cost, when a project is put into production.

This article is another introductory article to the Next.js + Strapi stack, we will also cover TypeScript, Data Fetch, Layouts, CI / CD and Deploy, but first of all we will cover security.

Below we will discuss, the most common security errors in web applications and how to mitigate or fix them in our Strapi + Next.js application:

XSS / CRSF:
XSS or Cross Site Scripting, is a malicious technique to inject code into our application and circumvent security to hijack data or manipulate a user's session for example.

CRSF or Cross-site request forgery, is when someone uses a malicious technique to get through a request either via Postman or browser to reach our database, delete user data for example, steal session data (like credit card , addresses, etc.) among other things.

Click Jacking:
Do you know when you open pages that tend to trick the user into typing data and in the end they end up sending that data to people they want to use maliciously? Or that they may have malware or exploits and install them on the user's machine?

Common vulnerabilities in Rest APIS:

DOS & DDOS (Denial of Service): When a hacker wants to take down an API, application or website, he can fire bulk requests for that API or endpoint.
Exposure of Sensitive Information: When we expose sensitive user data, especially without encryption in our API. Ids, emails, addresses, payment information, etc.
MIM (Man in the Middle) attacks: When a hacker tries to intercept client and server communication, with the intention of stealing data.
SQL Injection: Injection of code that changes the expected behavior of the API and the Database. Through an injection, a hacker is able to steal information, break the API, change its operation.
Insecure Direct Object References: When you expose an API with endpoints like / user / id / 30, and a user tries to access an ID that does not compete with it, and succeeds, you are exposing
Direct References for insecure objects.

Common vulnerabilities in GraphQL APIS :

/ graphql? query = {__ schema {types {name, fields {name}}}}:
If your GraphQL API is public, only with a query like this, the user who uses it, can see the entire schema of your API
Malicious Queries: Hackers can mount malicious queries, whether to steal data, corrupt your database, or bring down your API / server
Brute-Force: To avoid problems with hackers trying to break the data in your GraphQL API, you can use plugins like GraphQL Rate Limit, which will limit how many times the vulnerable fields of your query can be executed in a time interval.

How to avoid all this?

On Strapi:

Understanding the Strapi Configuration file & its security: Strapi has rich documentation that shows us how to guarantee the security of the CMS:
It has configurations for XSS, P3P, Hsts, X-Frame-Options (Clickjacking), CORS (very useful to define which domains can access your application, which headers can be exposed),
IP (Can configure which IPS see or not your application)
Credential Injection: Use a .env file, to avoid injecting credentials in the middle of your code
Validation: You can create a middleware to validate that your application data already exists and will not be duplicated, or you can also use a lib like Joi, to validate your API fields, but Strapi already has some native validations that you can define in your API models, only if you use MongoDB
Roles & Permissions: Ideally, you should create documentation for your API on which permissions and endpoints you will enable so that you don't end up making the mistake of allowing everything and offering risk to your API data
Policies: You can set your API's policies directly in Strapi's code through ./config/policies for global Policies and ./api/**/config/policies for local endpoints. It is an extra layer of security for your Strapi application. To set policies with GraphQL, Strapi's documentation has a page dedicated to that.
Data-Leak: You can pass a private: true parameter, within the parameter in your API model, to remove the value of being accessed by anyone. Click here to learn more
JWT: you can require the user to access sensitive endpoints of your application to be logged in and use JWT.
Exposure of Sensitive Information: Strapi allows to edit the controllers, which information can be accessed in the calls of the endpoints. You can delete certain fields and parameters from the results.

In GraphQL:

DOS (Denial of Service): You need to limit your queries. A malicious hacker, if discovered its GraphQL API, can mount a series of queries that can overload your server. This is a great article on the Apollo blog that teaches some cases of malicious queries and how to avoid them.
Setting Policies for Queries: You have to customize the Schema of your GraphQL API, setting the desired policies to have control of who or how to access what in your API
Unauthorized access: You need to disable the GraphQL Playground, which is already disabled in the production version of Strapi (you can disable it for other environments here), then your GraphQL endpoint is not maintained by a route but by middleware.

It is necessary to create a new middleware, which will check if the endpoint we want is / graphql and if the authenticated user is what we want:

module.exports = strapi => {
  return {
    initialize() {
      strapi.app.use(async (ctx, next) => {
        const handleErrors = (ctx, err = undefined, type) => {
          if (ctx.request.graphql === null) {
            return (ctx.request.graphql = strapi.errors[type](err));
          }

          return ctx[type](err);
        };

        // check if it's a graphql request
        if (ctx.request.url === '/graphql' && ctx.request.method === 'POST') {
          if (ctx.request && ctx.request.header && ctx.request.header.authorization) {
            try {
              // get token data
              const { id } = await strapi.plugins[
                'users-permissions'
              ].services.jwt.getToken(ctx);

              if (id === undefined) {
                throw new Error('Invalid token: Token did not contain required fields');
              }

              // check if the id match to the user you want
              if (id !== 'my-user-id') {
                return handleErrors(ctx, 'You are not authorized to access to the GraphQL API', 'unauthorized');
              }
            } catch (err) {
              return handleErrors(ctx, err, 'unauthorized');
            }
          } else {
            // if no authenticated, return an error
            return handleErrors(ctx, 'You need to be authenticated to request GraphQL API', 'unauthorized');
          }
        }

        await next();
      });


    }
  };
};

To be authenticated you need to send a JWT in the header. See here in Strapi's authentication documentation how to do it.

In Next.js:

Validating fields: The validation of form fields is not only used to guide your users, but also to guarantee the integrity of the information transmitted from the client to the server. This prevents a series of malicious codes from being entered into our Services. The user can still try to manipulate the data by editing the HTML in DevTools, but that is another problem.
CRSF: Passing the parameter Content-Type: application / JSON, in our requests, forces our application not to use simple requests, and protects against attacks
XSS: This guide is very useful and shows some rules that it is good to follow when developing our front-end application so as not to have a headache afterward on security and XSS issues. This Next.js plugin also helps to implement XSS Protection, helping the browser to sanitize vulnerable areas of your application.
Security Headers & ClickJacking: Using X-Frame-Options: DENY or SAMEORIGIN, you prevent third parties from being able to run your Next.js application within a frame.
The next-secure-headers plugin helps you with that. In addition to implementing FrameGuard, it also implements XSS Protection, contentSecurityPolicy, nosniff, noopen, forceHTTPSRedirect, referrerPolicy, expectCT.
JWT & Rolling Tokens: You can implement JWT, for the authentication of your App to guarantee the integrity of your API and access to it, this is a good tutorial that teaches this

More:
NextAuth.js: A plugin to help you with security in the authentication of your Next.js app

SSL:

One step before we publish our site for production is to set our domain and server to the HTTPS protocol. HTTPS protects our requests from being targeted by Man In the Middle attacks and is also crucial for SEO as it impacts Google's ranking.

Some ways to get free SSL certificates for your website are to use the service of:

APIS Caching:

Although it is not only a concern with security but also with performance, APIS caching can be recommended so that your site can work even in offline environments, but when it comes to dynamic data, it ends up being not recommended, only for data that is not. constantly change. This is a topic that requires an article just for him, but if you feel interested in knowing more about it I recommend reading the following articles:

Strapi's Safety Roadmap:

The Strapi team is planning some features that can help in future releases on security issues:

This is the Product Board link. In it, we see that the Strapi team plans features such as 2FA (Two-factor authentication), Rolling Token (JWT), SSO (Google, Twitter, Facebook, GitHub), among others that are already being tested: as Permissions and Rules per user and Permissions at field levels.

Checking tools:

There are some sites and tools on the web that test how secure our application is. Below are some of them:

Sentry: Sentry is a tool for monitoring web apps errors. It supports several technologies and platforms. It can be easily integrated with GraphQL, Strapi or Next.js. It has a free version for developers.
Sqreen: Sqreen is a webapps security monitoring platform. It can bring real-time data from potential exploits, protect you from attacks and malicious activities.
Strapi supports Sqreen.

First: create a Sqreen trial account
Second: set up your organization on the Sqreen dashboard
Third: set up Sqreen on Strapi

In Next.js you can also use Sqreen, but the configuration is a little more complicated

First: create a Sqreen trial account
Second: set up your organization on the Sqreen dashboard
The third :configure Next.js to use a Custom-Server
Configure Sqreen for Node.js

LGTM: LGTM is an open-source tool used by major players in the market, such as Google, Microsoft, Nasa, and Dell, which checks for vulnerabilities in your code through a repository on Github or BitBucket.
It has an automatic code review tool and is very powerful, it has alerts to warn you about problems in the code and also comparisons and history.
SonarCloud: SonarQube is a very powerful tool that not only checks for bugs and vulnerabilities in your code but also some parameters like Code maintainability, Test Coverage, Codesmells, Code duplication, it analyzes your code and can stop a P / R or M / R on Github, GitLab, Azure DevOps or BitBucket if it does not reach the expected code quality. SonarCloud also has a plugin for IDES that checks in real-time
Mozilla Observatory: Mozilla tool that will help bring Insights about the security of your website.
DigiCert SSL Tools: It will check your SSL certificate data, show possible vulnerabilities, the Certificate Chain and the Server Configuration.
Qualys SSL Labs: Tool a little more complete than that of DigiCert.
Pen-test Tool: Website Vulnerability: Website that has SQL Injection checking, XSS, Inclusion of files, Execution of remote commands, however, it is paid.
Sucuri SiteChecker: Sucuri is well known in the world of web security. Detects if your site is blacklisted on Google, if it has unsafe links, among other security parameters

Well guys, thanks if you got here and had patience, the intention was to have given you a general idea of how to mitigate and solve various security and vulnerability problems in web applications with Next.js and Strapi, before we started using Stack, being that the concepts mentioned here can be used and verified in any web application not only with Node.js and JavaScript / TypeScript but with other languages and that use Rest APIs or GraphQL Apis. This is a very extensive subject that could yield several articles, but I tried to summarize in this one.

References:

Why use Next.js + Strapi?

Ruben Marcus — Fri, 07 May 2021 02:59:14 +0000

At this article I will show you the advantages of doing a website with Strapi in the backend and Next.js in the frontend

at the time I wrote this article back in 2020, Directus was using an old Zend Framework in PHP that made a very interesting project full of features buggy,and not so easy to deploy and mantain as Strapi

But as Matt Williams stated in the comments the Directus team made an incredible effort rewriting their entire CMS in Node.js and soon in Laravel 8 too.

First of all… What is Headless CMS?

In short, it is a content management system like WordPress, Drupal or Contentful in which content management is separate from the presentation layer (Front-end).

The main advantage of this approach is that it is tech independent, which means that the website (can be made in SPA frameworks or as you wish), native apps or can be created using the tools or tech you want.

The main disadvantage is that you need to manage two or more web applications instead of one. (Which can be a disadvantage, depending on the formation of your team.)

There are CMS that come as Headless standard (API-based), and some that are GIT-based, and generate static websites.

And others that are also based on API but that do not come in this architecture by default and it is necessary to use plugins.

The advantage of being Headless and API-based by default is that:

you have a source of information and can make many applications for different devices from it.
The fact that it is a core functionality of the CMS, indicates that the chance of support and updates to the Headless API are greater, whereas if it is a plugin the chance of not being supported may be more likely.

If you want to know more about Headless CMS,than take a look here: https: /headlesscms.org/

Why use Strapi?

Strapi is an Open Source CMS, made in Node.js and MongoDb, it also supports MYSQL, MariaDB, SQLite and PostgreSQL.

Comes with easy deployment to AWS, Digital Ocean , Heroku and many other cloud services.

It has rich documentation and several tutorials on how to use the CMS.

It is possible to install locally via CLI or using Docker, or using online services such as Platform.sh or Digital Ocean, or wherever you want.

It is possible to do unit tests with Jest, or other test frameworks, since Strapi has a configurable webpack.

Strapi, also has webhooks to trigger actions for other applications.

Strapi's architecture is very simple and well-founded, it explains how to write plugins, how to model the Strapi API, how to manage the content to be exported.

Strapi's learning curve might be between low and medium, it depends on the developer's knowledge with Node.js and the concept of CMS Headless, if the developer has any doubts he can take a look at the existing examples, tutorials or documentation.

It is possible to restrict JWT apis calls to Strapi user groups.

Internationalization is only possible with a workaround, creating fields suffixed by languages

The main competitor of Strapi in the Node.js world is Ghost, and OpenSource is Directus (made in PHP), also WordPress with its Rest Api that since version 4.7 is part of the WordPress Core and no longer made by plugin.

Of these 4 Open Source options, I consider Strapi the better, because you understand how simple it is to manage and extend it.

WordPress in addition to security issues, has a different base concept than Strapi. You can achieve the same goal as Strapi, but by making more settings and using various plugins.

Ghost presents a somewhat similar scenario, but often to do the same thing you do on Strapi you will need more work for the same thing.

Ghost is very good on the security side, but on the content side, Strapi is simpler and more complete.

Directus is one of the CMS that presents, a proposal very similar to Strapi, but its stack is made in PHP, and has bug reports critical by users.

Why Next.js?

With the rise of SPAS frameworks, going from Angular.js, React, Angular 2+ and Vue,a major faced problem from apps rendered on the client,face it is the issue of SEO.

Frameworks like Next.js come to solve this problem.

Rendering the application via SSR (Server Side Rendering) or SSG (Static Site Generation),than the search engine can read the content of your page, and render it for show in its results.

But the benefits go beyond that. Next.js increases the loading performance of your application.

In a basic test on Google LightHouse (we will address this soon), an application with create-react-app x a Next.js SSR application, had a first meaningful paint with 87% less time than a React CSR application (Client-side Rendering), this is due to Next.js already render part of your application on the Server, bringing the content on the screen before loading everything on the client.

It has a folder and links scheme that also allows the lazy-loading of modules, as well as automatic code-splitting.

You can choose which pages you will render on the server and which you will render statically, making it a Hybrid app.

Next.js supports AMP (Acellerated Mobile Pages): Where it wont render anything from Node.js and React, and only pages in AMP format.

Next.js also supports the entire range of CSS universe, from preprocessors such as SASS, LESS and Stylus, as well as CSS Modules, Styled Components, CSS-in-JS, TailWind CSS, Bootstrap etc.

Next.js has a very strong focus on performance, and has tools for you to measure that. (This will be the subject of a separate article).

We are able to use Next.js also with TypeScript, assuring how we handle our application data using interfaces and types.

Inside Next.js you can also do DynamicImports, using the ES2020 syntax, and generating components dynamically.

These are some benefits of Next.js, in addition to solving and helping us with the SEO problems of the SPA frameworks, it gives us the entire React ecosystem, to be able to work, in addition to helping us, with a lean structure and a very rich documentation.

some companies using Next.js: GoDaddy,Netflix,Marvel,Invision App, Tencent, Tiktok, Uber, Trip.com, HostGator, Auth0, Binance, Staples, TicketMaster, Playstation, IGN, AT&T, Hulu, Twitch, Nike, Lego, Material UI, Expo, Ferrari, Avocode, Styled Components, Volvo, The Economist,Workable, Vodafone, Coinmarketcap, Monday, Elastic, History Channel , A&E Tv, Lifetime, Hackernoon, Spotify, Pier, DAZN, Apify,CloudBees, Deno,Crazygames.com

Next.js x Nuxt x Angular Universal x other React SSR Frameworks:

There are other frameworks, which compete directly with Next.js

The idea is not to make a comparison between them. But basically each one follows a tool, be it Nuxt.js with Vue, or Angular with Angular Universal.

The idea is not to make a comparison here, because that would be a theme for an entire article, just to give an idea that there are other options on the market.

Within the React ecosystem there are other ways to achieve the same goal, either with After.js, Razzle or React-SSR.

Starting witn Next.js + Strapi: Boilerplates

Boilerplates are ready to use codes that allow us to start an application without having to configure it from scratch.

They are very useful to go out coding our application without wasting time with installations and configurations.

Below I will mention some that I think are good to start in the Next.js and Strapi universe:

Strapi Next.js Blog Boilerplate (made by the Strapi team)
Next.js Strapi Example (made by the Next.js team)

References:

Strapi Documentation
Next.js documentation
10 Reasons you should use a Headless CMS