Lines of code
Bareserver offers a simple, domain-specific syntax for creating RESTful web services.
The primary reason for building Bareserver was to get an API that makes web services feel like local development: you take in arguments and send back return values. There are no
response objects so you never need to worry about request bodies, argument parsing or return value serialization. And you don't need a separate middleware to get those
async calls working.
The small API documentation fits into two pages. You learn to use Bareserver it in minutes, and you rarely need to go back for docs when building services.
Bareserver starts immediately and the runtime is extremely fast because it's a very thin wrapper above the raw Node HTTP interface.
Bareserver is opinionated — it is optimized for one specific purpose: creating RESTful web services. Express, on the other hand, is unopinionated: it is more flexible, more configurable, and has more features. However, this comes with an expense: Express.js API documentation is 53 sheets of paper when printed.
Bareserver is used extensively on this website. We currently have 91 routes defined on our CRM. We even used it as the frontend to our analytics service for 38 different websites with millions of requests on a single day. It never crashed. A small codebase is easy to stabilize.
All the HTTP verbs, like
patch are supported.
Get additional arguments from the path itself.
Define contexts for nested routes and shared variables.
Global response manipulation
Manipulate the return value globally before sending it back to the client.
Multipart requests are automatically detected
Credits to busboy for doing the heavy lifting, which is the only NPM dependency in the alpha version. It's optional if you don't need file uploads.
Global error handling
Handle user- and system errors in one central place
request to bypass Bareserver and get raw access to the Node's
http.ServerResponse objects. Good for non-REST communication like WebSockets and Server-Sent Events (SSE).
Here's a primitive “hello world” benchmark aiming to evaluate the framework overhead.
1,2 GHz Intel Core m5, 8 GB 1867 MHz LPDDR3
autocannon -c 100 -d 40 -p 10 localhost:3000
For each server, we ran the benchmark two times and took the average from the second run. However, those are still ballpark figures since we had quite a bit of variance on the benchmark results. Also worth noting that server benchmarks tend to favor their solution. For example, Fastify and Foxify beat each other on their benchmarks.
Regardless of the results, Bareserver is definitely one of the top performers because it's such a thin wrapper above the raw Node HTTP interface.
Bareserver is private alpha, but beta-testers are welcome.
Please note that it takes some time before you get the access. There's some work left before this is in beta stage.
Frequently Asked Questions
Where is this coming from?
What's up with the word “opinionated”?
Opinionated design is at the heart of minimalism. You must make choices to make a great solution to a specific problem. REST and JSON are great choices on our opinion. Graph QL might also be good, but not in our opinion.
Why should I care about the lines of code?
Large codebases are harder to extend and keep in control. They are more complex so it takes a longer time to fix issues. Complexity is also related to performance: the more to execute, the slower it gets.
How is this different from Fastify?
Fastify is another unopinionated framework with 3,516 lines of code, 58 npm dependencies, and 122 plugins. We think Fastify is very similar to Express.
How about Restana, Restify, Koa or Polka?
Same thing. They embrace unopinionated design and are designed for many different use cases.
Why not use arrow functions on the examples?
We think old school function declarations are clearer, especially with the
async keyword. Explicit is good. Or maybe we are just old farts.
Why not give GitHub access now?
The private version of Bareserver is in active use on this website, but we're just getting started with the open source version. The primary reason for writing this article is to collect initial feedback and validate the demand.
Eventually, if there is interest, we want to make a solid release with good documentation, Long Term Support (LTS), prepare resources for support and issues, setup contribution guidelines and figure out a license.
Who are you?
Where is this project heading?
Towards stability. We strive for great API, handy syntax, zero issues and Long Term Support. Feature richness is not our goal.