Implementing AppAsap’s tRPC-REST Integration
Ibrahim Amin – Tech Hive
August 2023
1 Abstract
This document describes a stage one implementation
of integrating generic RESTful API generation func-
tionality into the already existing tRPC API genera-
tion, this is part of sprint 6 with an estimated time
span of (7/23 - 8/5), this should describe the approach
taken to achieve that. I will talk about the rules that
I’ve set for the implementation design, then describe
the steps needed to finish that implementation. I will
also try to constructively criticize the implementation
by mainly talking about the disadvantages and the
things that can possibly go bad using this implemen-
tation and finally talk in general about operations we
can perform on the output API like automatic CI/CD,
deployment options, scalability, etc...
2 Introduction
AppAsap is currently able to generate an application
backend including an admin dashboard to interact
with that backend, this backend API is implemented
using tRPC routes, and both the dashboard and
the API are generated in a single monorepo that
uses turborepo from Vercel. We aim to provide two
variations, one for the API, and the other one for the
admin dashboard, also we should be able to choose
which implementation we want to generate (REST
or tRPC). The API should have a RESTful variation
generated in a monorepo with the admin dashboard
variation that is compatible with that RESTful API
and is able to communicate with it over HTTP out
of the box. The implementation priority is for the
RESTful API and not the admin dashboard because
the dashboard needs an API to call.
1
3 Rules
This section sets a guideline to follow so that we know
what is the scope of the side effects that this imple-
mentation will have on the existing code base. Rules
include the following:
3.1 Isolation
The REST generation implementation should and will
be isolated from the tRPC implementation, so if there
exist any breaking changes after the merge, we most
likely know that this happens on the REST generation
and not on generating a tRPC API, because integrat-
ing REST didn’t introduce any breaking changes to
the stable tRPC generation process.
3.2 Mutual Exclusiveness
The client should be able to set a flag using the UI so
that the backend generator either generates a tRPC
API or plain REST API but not both at least for now.
If we followed the first rule of implementation isolation,
this won’t be hard to ensure.
3.3 Reusability
The output RESTful API will be using the same ser-
vice and validation that the output tRPC API uses,
it should not introduce new service or validation lay-
ers but try to adapt the current implementation to be
compatible with it.
4 Steps
This section will give an overview of the steps taken
to achieve an integration that follows the rules I set
above.

Figure 1: Controller Template Example Output
4.1 Templates
Referencing the pickle repository, we should try to
adapt the templates implemented there and move it
to the appasap-beta codebase, the template we are
interested in the most is the template containing the
swagger jsdocs, we might also transfer the template
containing the code for the entry point to the server
(the code initializing the express server) if it doesn’t
need many changes, otherwise, we can rewrite it to fit
our needs. We are not interested in the Prisma schema
template because it’s not relevant to us anymore, it
was just adding a datasource and a generator defini-
tions to the Prisma schema, but we already have these
definitions in the input Prisma schema when dealing
with the appasap-beta code base.
4.2 Adapting Templates
After transferring the relevant templates we will most
likely need to change things including but not limited
to the following:
• Naming.
• Import paths inside the templates.
• Optionally add meaningful JSDocs comments.
This will make these templates usable inside the
appasap-beta code base.
2
4.2.1 Controller Template
I will provide an example output of the controller tem-
plate for a single resource and you should understand
the pattern, on the left is an example output for the
user resource, it uses the createCRUDRouter()
helper function, helpers are a topic on themselves and
I will talk about them later in the document, but the
main idea is. any output backend (the API part) will
be divided into two folders entities and helpers, en-
tities contain generated code and each entity should
be divided into three components controller, service,
and validator, but helpers doesn’t contain generated
code, these are (at least in development environment)
injected at generation-time, also as a note, a REST
API helpers won’t be the same as the helpers from a
tRPC API but might reuse some of it.
4.2.2 Service Template
The service template is simple, this is an example of
the output code related to a user resources:
Figure 2: Service Template Example Output
In contrast, the service template uses another helper
called crudService(), which automatically provides
business logic for Create-Read-Update-Delete to all
entities generated, it can also be extended by adding
custom business logic
4.2.3 Validation
This document won’t go over templates or code related
to validation, or how to adapt the current validation
layer implementation to fit the RESTful API, this is
done for simplicity and because I need more research
on this and need to study more possible scenarios be-
fore I am able to settle on the details.
4.3 Helpers
At this point, we have templates capable of generat-
ing an extendable CRUD controller and an extend-
able CRUD service/business logic that the controller
will use, each entity will get its own (controller, ser-
vice) pair. But looking at the templates’ code above,
we see that the implementation is abstracted and pro-
vided via the helper functions, namely, the create-
CRUDRouter() for the controller implementation
and crudService() for the service implementation. It
is not important to show the code of these functions,
it is important to understand the idea that the entities
will use helpers to implement most of their function-
ality and that entities are generated but helpers will
most likely be pre-written and injected. These are the
current helpers for tRPC APIs:
• auth
• cache
• configs
• cryptography
5 Standard
This section talks about assumptions in the implemen-
tation, the front-end client should take these assump-
tions into consideration for a working predictable re-
quest life-cycle.
5.1
6 Improvements
In this section, I will talk about the things that I don’t
necessarily like about this implementation and that
have gaps for improvement.
6.1 Extension
We should be improving the way we extend the output
controller and service, I would prefer a more structured
way of handling that and not to leave things very flex-
ible, at this point, we write customRoutes in the same
file as the controller entity which isn’t very scalable,
so this probably needs to change.

• database 6.2 Usage

• deploy A CLI tool to scaffold boilerplate code for the con-
troller, service, or validator would be nice so that it
• error
supports the first idea of having a structure and mak-
• generic-crud ing the coder follow it and also save him time.

• mail
6.3 More
• monitoring
This is currently the end of the document, I will add
• payments more as I go deeper through the integration process.

• server
• types

If we can adapt a variation of all of these helpers to

work with a REST-based API the job would be done
(some of them aren’t implemented yet even for tRPC
APIs). At the time of writing this, some helpers are
already adapted to fit REST usage (generic-crud
excluding validation, and database Prisma helpers).