Show HN: I built a web framework in C

2025-10-0912:45420218github.com

A fast, lightweight web framework in C for building modern web applications - ashtonjamesd/lavandula

Show article

Lavandula is a lightweight, fast, and intuitive C web framework designed for building modern web applications quickly. It focuses on simplicity, performance, and productivity, providing all the essentials without the bloat of heavier frameworks.

#include "lavandula.h" // define a route for your app
appRoute(home) { return ok("Hello, World");
} int main() { // initialise your app App app = createApp(); // register a route in your app get(&app, "/home", home); // run the app runApp(&app);
}

Controller and routing system
HTTP endpoint support (GET, POST, etc)
Controller local/global middleware pipeline
Minimal dependencies (pure C)
Quick project scaffolding via the CLI
Built-in unit testing framework
Environment variable support
Built-in logging
SQLite integration
Built-in JSON library

HTTP JSON body parsing
Session cookies
CORS policy configuration
Lavender ORM
Embedded Lavandula (ELA) HTML templating engine

Rate Limiting
Static file serving
PostgreSL, MySQL integrations, etc
Potential dependency injection framework
Route/Available endpoint listing
JSON model and function scaffolding
- lavu model User name:string age:int
- generates User struct, JSON serialization, CRUD endpoints in user_controller.c
- URL parameter parsing and routing

To install Lavandula, follow these setps.

git clone https://github.com/ashtonjamesd/lavandula.git
cd lavandula

You should see the following:

[SUCCESS] 🎉 Lavandula installation completed! Quick Start: lavu new my-project # Create a new project cd my-project lavu run # Run your project

Documentation:
 GitHub: https://github.com/ashtonjamesd/lavandula

You should now be able to run the Lavu CLI tool. Refer to api.md for how to use Lavu.

Output:

Setting up Lavandula project 'myProject'...

-> Created myProject/lavandula.yml
-> Created myProject/app/app.c
-> Created myProject/app/controllers/home.c
-> Created myProject/app/routes.c
-> Created myProject/makefile
-> Created myProject/tests/tests.c

🎉 Lavandula project 'myProject' setup finished successfully!

Next steps:
  1. cd myProject
  2. lavu run

Your application will run on http://localhost:3000/.

Read the docs
- Developing with Lavandula
- API Documentation

Contributions are welcome. Feel free to submit pull requests or open issues for feature requests or bugs.

Some things that probably need looking at are:

memory leaks
outdated and unfinished documentation (API changes warrant a docs update)
The JSON library does not currently support nested lists
Some tests need to be written...

Lavandula is registered under the MIT License.e

Read the original article

Comments

By faxmeyourcode 2025-10-0914:123 reply

This is some of the cleanest, modern looking, beautiful C code I've seen in a while. I know it's not the kernel, and there's probably good reasons for lots of #ifdef conditionals, random underscored types, etc in bigger projects, but this is actually a great learning piece to teach folks the beauty of C.

I've also never seen tests written this way in C. Great work.

C was the first programming language I learned when I was still in middle/high school, raising the family PC out of the grave by installing free software - which I learned was mostly built in C. I never had many options for coursework in compsci until I was in college, where we did data structures and algorithms in C++, so I had a leg up as I'd already understood pointers. :-)

Happy to see C appreciated for what it is, a very clean and nice/simple language if you stay away from some of the nuts and bolts. Of course, the accessibility of the underlying nuts and bolts is one of the reasons for using C, so there's a balance.

By citizenpaul 2025-10-0914:5815 reply

> I'd already understood pointers.

Ok I hear this all the time. Are pointers really that hard for so many people to understand? I'm not trying to brag it took me I think like 15 minutes to grok them from learning about them the first time. I'm sure it took me longer to be proficient but I don't get this legendary difficulty aura that seems to surround their existance.

Also yes nice project.

Job app complete projected archived and abandoned in 3...2..1... :). I hope not.

By ActorNightly 2025-10-0923:095 reply

The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.

Then when you start using pointers, it makes sense. If variable is a pointer, that means its a memory location. *variable is a way to get that data. Then arrays is just a wrapper around pointer arithmetic.

Whereas with CS, you learn about variables first, which is an abstraction on top of memory, and pointers don't make sense in this regard.

This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals

By rockemsockem 2025-10-102:381 reply

> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals

This is largely not the case in my experience. They probably understand the lower level details of manipulating memory better, but there's a lot more to developing software than understanding that memory is a specific place.

By ActorNightly 2025-10-1016:481 reply

>but there's a lot more to developing software than understanding that memory is a specific place.

Yep, and all of that is derivative from how to organize memory. Classes are just more fancy structs. Object creation is memory initialization. Processing flow and code reuse is recognizing memory access patterns. ETC and so on.

By rockemsockem 2025-10-1016:511 reply

All of software engineering is not derivative of memory organization. Algorithm efficiency for example is entirely independent of physical memory implementations. Just because an algorithm may use a set or an array does not make it derivative.

By catlifeonmars 2025-10-110:211 reply

> Algorithm efficiency for example is entirely independent of physical memory implementations

This is wrong. Lots of algorithms behave completely differently based on memory layout. There is typically an inflection point where big O effects start coming into play, but at most scales, memory locality tends to be way more important in determining how efficiently something runs.

By rockemsockem 2025-10-1523:53

That's why I said algorithm efficiency and not wall-clock time or something else implying that I was talking about real-time.

If your algorithm is poorly designed and does significantly more work than necessary then that is independent of physical memory.

It's like you are trying to misunderstand me.

By hunter-gatherer 2025-10-100:59

Springer press has a book "Programming for Engineers and Scientists" or something like that, which is the first book I picked up to "self teach CS". From the get go pointers are involved and explained in this linear memory model and explained how they work on the stack and what not. I always thought this was the best approach; the reality is taught first, the abstraction (syntax) second. Not sure why so many programming books do it the other way.

By Jataman606 2025-10-107:441 reply

> The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.

Can't agree with this enough. The moment i finally understood what pointers are was when I landed embedded job and during debugging session I looked at memory browser that showed my variable at exact address in memory. After that all about pointer arithmetic and even function pointers became clear as day. Something at least 3 teachers weren't able to explain clear enough.

By frabert 2025-10-108:57

You can do the same with regular, non-embedded programs in a debugging session

By wmwragg 2025-10-1010:52

The book "Understanding and Using C Pointers: Core Techniques for Memory Management" by Richard M Reese, is a great way to learn pointers

By messe 2025-10-104:341 reply

> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals

Hah, like fuck they are. The worst code I regularly have to review is written by EE grads. They have less of an understanding of pointers than the people in the office with a CS background.

By ActorNightly 2025-10-1016:50

I have probably like 2000 interviews under my belt across multiple companies. Your experience is an outlier. EE/ECE grads generally can write better optimized software - the only downside is that they aren't thinking as much of maintainability in design of interfaces, but thats a problem that is solved with LLMS

By noufalibrahim 2025-10-0916:021 reply

It's a rabbithole. Pointer to array of structures that have pointer fields. Array of pointers to structures etc. You pass them around and trip over the passing semantics, uninitialised pointers etc etc.

By citizenpaul 2025-10-0916:264 reply

Hmm. Perhaps I've just never encountered a hairy enough situation with them? That's what the eternal thought tracker notepad on my desk is for though. Maybe people are trying to do it all in their head? Pen and paper are too old school for the cool new 1000x devs?

I still feel like this argument could be transferred to nearly any concept in CS though. Abstract enough anywhere and you will always start exceeding the brains working memory.

By jacquesm 2025-10-100:44

A simple properly implemented doubly linked list or circular buffer is already above the level of most beginner C programmers. Though they're great exercises.

By jcelerier 2025-10-0917:27

I don't think I would be comfortable saying I understand something if I'm not able to get it 100% clearly just from my thoughts and re-explain it to someone

By 6510 2025-10-0922:232 reply

Everything is just numbers, then we pretend they are arrays, pointers, objects, classes, floats, websites, applications, certificates etc.. The imaginary array can really only contain numbers but we can pretend the numbers are other things, unicorns, rainbows, laser unicorns etc

We are just pretending, there is nothing to understand?

By moron4hire 2025-10-104:551 reply

To take this a step further.

They aren't even numbers. They're voltage-high and voltage-low signals.

Numbers don't even exist! You'll never find a 2 in nature. You'll find two things, but you'll never find the 2 itself.

And all 2s are the same 2. But every voltage signal representing a 2 is a completely different voltage signal. Sometimes they aren't even voltage signals! Sometimes they're magnetic flux signals! Sometimes they're electrical field signals! Sometimes they're photons modulated down a wire made of glass!

But the 2 they represent? Not even that is 2. It's 10!

By 6510 2025-10-1012:15

Right, I couldn't find the words. Numbers are also imaginary technology but if you treat high as on and on as 1 and low as off and off as 0 it's so close to reality that it will be hard to find exceptions in software.

Like we pretend it is high for convenience while we really mean higher. For all practical purposes our imaginary world works! hurray!

By jaza 2025-10-111:07

I can accept that everything else is fake, but UNICORNS ARE REAL, dammit!

By noufalibrahim 2025-10-125:43

That's what most people do. Draw diagrams. Some things like pointer arithmetic which are language features and not just arrows to things and indirection are easy to get wrong though

By lelanthran 2025-10-0918:062 reply

> Are pointers really that hard for so many people to understand?

Apparently they are; I believe it's the indirection that gets people.

Most learners aren't really taught basics properly - they learn that a variable "contains" a value, when instead they should learn that all values have a type, and some variables hold values.

> I'm not trying to brag it took me I think like 15 minutes to grok them from learning about them the first time.

I can't remember not knowing pointers, so I can't really tell you how long it took for it to click, but I do know that I had done a non-trivial amount of assembly before I used C, so maybe that helped/.

By ranger_danger 2025-10-0918:521 reply

I think it would help a lot if pointers were taught to people from the perspective of how they actually occupy memory, and what the value it stores in memory represents, and then how that value is an address that is followed when a pointer is "dereferenced", etc.

It seems a lot of people assume that pointers don't actually consume any memory and then get confused trying to understand it that way.

By EvanAnderson 2025-10-0919:221 reply

Strong agreement.

I came at C after doing 6502 and 8086 assembler. Pointers just made sense because working with indirect addressing and understanding how things were stored in memory already made sense.

By bionsystem 2025-10-0921:541 reply

The way a lot of teachers teach it is plain trash. I was raking terrible grades in OCaml and C before a student showed me what I needed to know in 15 minutes, and then I would kill it in the remaining exams. Same thing happened to my 68000 course. It didn't happen with every teacher but still, some people really need to get some better pedagogy.

By 6510 2025-10-1011:151 reply

The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.

By lelanthran 2025-10-1012:302 reply

> The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.

What does academia believe, then? I don't know what the negation of "If you know something you can teach it" is.

That if you don't know something, then you can't teach it?

That if you know something you can't teach it?

That if you don't know something you can teach it?

By supportengineer 2025-10-0921:242 reply

Pointers make perfect sense.

Now dependency injection, that's some magical bullshit right there.

By munchlax 2025-10-108:02

If you have a class whose constructor depends on an instance of something else, you can instantiate that first and pass it on.

That's all there's to it.

You can do DI in your own startup code and have some logic in there that substitutes mocks when running under test. Or you could change the logging when debug is enabled. Hardly rocket science. If you can write code, you can write the startup code.

If your team likes patterns, dont mention dependency injection unless you're confident it wont get replaced with the framework of the day.

See https://www.jamesshore.com/v2/blog/2023/the-problem-with-dep...

Frameworks turn your DI code into highly complicated configuration. The end result is a giant lump of code whose only achievement is hiding the new operator and possibly also someones job security.

By throwaway2037 2025-10-1013:51

    > Now dependency injection, that's some magical bullshit right there.

I see you there! Joking aside, for me, I also struggled a lot with DI when I first saw it in Java. The ridiculous frameworks that hid all of the details drove me crazy. Even Google Guice was supposed to be more clear, but it was never as clear as... Eventually, I settled on hand-writing the wiring in one giant 1,000+ line function that builds the entire object graph on start-up. Then I could really understand DI because you could actually read (and debug) the code doing the "wiring" (building the object graph).

By jug 2025-10-0922:382 reply

The worst thing with C pointers was for me that the asterisk is inexplicably used both to declare a pointer and a COMPLETELY different operation of dereferencing a pointer.

I still don't understand this decision. I think it should've been like int^ p = &i; ... or ... int i = *p;

Everything clicked ironically when I went even deeper and studied assembly language. Then following pointers to data vs just reading pointers becomes very clear and explicit.

By sgsjchs 2025-10-0923:481 reply

> I still don't understand this decision.

Variable declaration `T v;` means "declare `v` such that expression `v` has type `T`". Variable declaration `T *p` means declare `p` such that the expression `*p` has type `T`". etc.

By kopirgan 2025-10-103:14

Nice explanation!

By tealpod 2025-10-107:061 reply

> asterisk is inexplicably used both to declare a pointer and a COMPLETELY different operation of dereferencing a pointer.

This is the most confusing concept of pointers. I feel this could have been easily avoided with different character like ~ or ^ or other.

By 1718627440 2025-10-1013:43

Why? In C all the declarations work like that:

    float * (*foo(int *)) (int);

foo is something, that can be called with an 'int *', which results in a pointer to something that can be called with an 'int', which results in something which can be dereferenced, which is a float.

By diegof79 2025-10-100:071 reply

Understanding the concept is easy.

The problem arises when you start to mix memory management with more complex structures.

It’s extremely easy to make mistakes, and you must be very careful about ownership and clean up. Those things are not strictly related to pointers, but in C, it’s inevitable to use pointers to handle them. That's why people say pointers are hard.

By moron4hire 2025-10-105:16

Yeah, it's one thing to understand "a pointer is a location in memory". It's a completely different things to understand what to do with that information.

When I first started learning to program, it was in C, with one of those "Sam's Learn Yerself a C++ in Eleventy-Three Days" books. I was, like, 15 or something. This was long enough ago and my family was just barely poor enough that we didn't even have the Internet yet.

The book explained memory. That was not hard to understand. But we had been using stack-allocated variables through several chapters in the book so far. I didn't get why you would ever want anything as a pointer. If I wanted to write a program to add 3 and 5, why wouldn't I just say "int x = 3;"? Why bother with this stupid dereferencing syntax? Given that the author chose to explain pointers by first explain the address-of operator on stack allocated variables, it felt particularly perverse. The regular, ol' variables were right there! Why but just use them

I didn't have a concept yet of what one could even do with programming. Hell, just a few years prior to that point, I was pretty sure all of the other programs on my computer were written by massive teams of wizards manually typing out 1s and 0s.

I still managed to bungle on and write code. But my programs in C never really worked well. Though, they still worked better than my classmates' versions! Then, in my 2nd year of college, I had transferred universities and the new place taught in a Java.

Java was disgusting. It was so verbose. Why did we need all these weird, multi-sylabic, period-infested function calls to do anything? Why was it so slow? Why couldn't I write ASCII-art graphics with it? Why couldn't I run my programs on my friend's computer?

It wasn't until I had taken computer architecture that I gained a much better understanding of what any of all these computer things were meant to do. I ended up implementing a basic scripting language in Java. And then, suddenly, I understood pointers.

By DanielHB 2025-10-0917:54

> Are pointers really that hard for so many people to understand?

Yes, anyone who has taken algorithms and data structures class in C knows that some people just don't get it.

Also the way people teach it tends to be bad, before teaching pointers you need to teach Stack and Heap at a conceptual level.

By codegeek 2025-10-0919:032 reply

"Are pointers really that hard for so many people to understand?"

The * vs & always gets me and not to mention if I ever have to deal with Pointer Math.

By bionsystem 2025-10-0922:111 reply

Think of it as types. All of the following are the same thing (declare p as an int* type). It's important for the end :

  int * p;
  int *p;
  int* p;

Now remember that the type is a memory address. I'm sure it is semantically wrong for whatever reason somebody will explain but it helps to think about it. So you can do :

  int my_number = 6;
  int* p = &my_number;

Both sides of the "=" are the same type (int* is an address, and &my_number is also an address, the one of my_number).

Now p is a pointer (or an int* or an address), and *p is... an int ! So this is totally valid :

  printf("%d\n", *p)

and for anything else than int you need to malloc that so you will see a lot of :

  my_struct* s = malloc(sizeof(my_struct);

which makes sense because malloc returns an address (the beginning address of the content of s ; yet again somebody will tell me I'm wrong to call it "the content of s" so sorry for that).

  my_struct* // is the type of s, it is an address
  my_struct // is the type of *s (some custom type of size sizeof(my_struct))

By 1718627440 2025-10-0922:221 reply

> int* p

I don't like that syntax, because it confuses people. It might be sensible to think of the type as (int *), but C just doesn't work this way. You might never declare more that a single variable in a statement, but it still gives people the wrong intuition.

By usefulcat 2025-10-104:312 reply

> int* p

I very much prefer that syntax, because the '*' is part of the type, not part of the variable name.

> You might never declare more that a single variable in a statement

    int a, *b, c, *d;

Yes, you can do that, and in fact if you want to declare multiple pointers on the same line, you are required to put a '*' in front of every pointer variable name.

Personally, I've always considered this to be a defect of the language. Would it really be so awful to have to write instead:

    // Both are of type 'int'. Pretty straightforward.
    int  a, c;
    // In my fantasy world, both of these would be of type 'pointer to int',
    // but IRL b is a pointer and d is an int. fun!
    int* b, d;

But of course that's not the language we have.

I'd be very curious to know the motivation for requiring a '*' in front of each pointer variable name, as opposed to once with the type. So far the only ones I've thought of (not mutually exclusive) are:

a) we REALLY love terseness, and

b) ooh look at this clever hack I came up with for variable declaration syntax.

By 1718627440 2025-10-1013:24

> because the '*' is part of the type

I agree with you that this is an obvious mental model and it might be true for other languages, but this isn't the model that the C language has, which reveals in the fact that:

   int* a, b;

does not declare two pointers.

You can see it like this: C does not have a way to declare a variable to be a pointer to int. In C you can only declare an expression with a variable to have the type int.

That's why I don't like this syntax especially for beginners. It is deceiving. It leads to people thinking it works differently than it really does and coming up with weird mental models. For example, that the unary '*'-operator has two meanings: dereference and declaring a pointer. Than they say a pointer should better be denoted by '&', because that's the address-of operator. But that's wrong, unary '*' always means dereference. You don't declare 'a' to have type 'int *', you declare '*a' to have the type 'int'!

It's the same with array syntax (and also with function pointers and really every declaration):

    Java:  int[size] a;

    C:     int a[size];

I agree that it doesn't cause problems for people who are experienced in the declaration rules of C, and it might never cause confusion if you never declare multiple variables in a line (I never do, because of diffability), but when teaching it leads to the wrong user model. Show 'int* a, b;' and people are confused, show 'int *a, b;' and it is obvious how it works.

By Hunpeter 2025-10-108:50

Someone said in another comment, that it makes more sense together with the dereference operator, so int *var means: "dereferencing var gets you an int."

I don't really know C, but personally prefer your version. However, I can also get behind considering the * to be part of the variable, rather than a type: "var is a pointer that happens to hold an int". I mean, maybe they could have used the & operator meaning "var is an address holding an int"? Honestly, it just feels like there's too much tradition and legacy and so on, and what one considers intuitive is the thing that they're most used to.

By TZubiri 2025-10-0919:20

*pointer = what pointer points to &thing = address of thing

By faxmeyourcode 2025-10-0918:25

Pointers in and of themselves are not difficult to learn on their own, but when you're learning them alongside your first programming language, it's just adds to the difficulty I think.

I think a lot of noobs learning C struggle with pointers especially because there are no good error messages besides "segmentation fault" :D

By copperx 2025-10-0915:511 reply

The concept is straightforward. The syntax isn't. That's why cdecl.org exists.

By citizenpaul 2025-10-0916:28

C gibberish to English gave me a chuckle thanks.

By leptons 2025-10-0917:28

I learned assembly language long before I learned C, so pointers took me about 2 seconds to understand. I suppose it may depend on previous experience.

By bsder 2025-10-100:26

> Are pointers really that hard for so many people to understand?

Yes. Especially pointer to pointer to ...

The big problem is that arrays are conflated with pointers because C doesn't do slices. If C had slices, people would naturally avoid pointers except in the cases where they were genuinely necessary. That would make teaching pointers vastly easier.

By wkjagt 2025-10-0916:52

I understood them on a superficial level when first learning about them, but it only really clicked after having done assembly.

By dingdingdang 2025-10-0918:211 reply

The legendary status is also enhanced by the absolute nightmare that pointers enable if used with indiscretion or high level proficiency - a triple pointer is a good example for me but there's many many more, and arguably worse, examples out there.

By koolba 2025-10-102:09

My favorite is pointers to functions passed as args for things like supplying a comparator. With more opaque void* args for customizing things even further.

By resonious 2025-10-107:39

As a 16 year old who learned programming by hacking together bad ActionScript3 flash games, it took me way longer than 15 minutes. Once I got it I got it and there was no mystery from then on. But there definitely was a hurdle.

By assimpleaspossi 2025-10-0916:011 reply

Same here about pointers. Perhaps it's cause I started life as an electronic engineer and understood memory addressing from the chip level but I, too, don't understand the struggle others seem to have.

By citizenpaul 2025-10-0916:33

I started in networking so there were a lot of memory/bit-logic/binary concepts piled on early maybe that is the case.

By ashtonjamesd 2025-10-0914:241 reply

Wow! That really means a lot because I always make a lot of effort to make sure my code is just that :)

Appreciate you saying that!

By jacquesm 2025-10-0915:05

You've done a couple of things right: very few dependencies, simple, easy to understand code. C gets hairy when you try to be clever.

I'm busy writing some of the most optimized-but-still-portable code that I've ever written and it is very interesting to see how even a slight difference in how you express something can cause a massive difference in execution speed (especially, obviously, in inner loops). Your code is clearly written from what your comfort zone with C is and I'm really impressed by the restraint on display. At the same time, some of the code feels a bit repetitive and would benefit from more universal mechanisms. But that would require more effort and I'm not even sure if that is productive. One part where I see this is in the argument parsing code as well as in the way you handle strings, it is all coded very explicitly, which substantially increases the chance of making a mistake.

Another limitation is that using AI to help you write the code means you don't actually understand what it does, and this in turn may expose you to side effects that you are not able to eliminate because you did not consider them while writing, it is as if someone else gave you that code and asked you to trust them they did not make any mistakes.

By codegeek 2025-10-0914:302 reply

People, stop trying to be so serious and nitpick this project. This is a great example of an actual HN worthy share. Someone built a cool project and explored the possibilities with C. This is not something we need to analyze with "oh can it replace PHP" etc.

Good job OP. Now if you can add HTML templating, this may become a complete framework :)

By ashtonjamesd 2025-10-0914:53

Thank you, I really appreciate you saying that!

Yes it's on the backlog and will be fun to implement :)

By whatamidoingyo 2025-10-0922:22

As someone learning C for fun, I agree. This project is awesome!

By hgs3 2025-10-0914:311 reply

The code is very readable and well organized. My only major critique is that there's very little error checking, e.g. there are many calls to snprintf and malloc without checking the result. There is also an unused loop here [1].

As an aside, I don't see any support for parallelization. That's fine for an initial implementation, but web servers do benefit from threading off requests. If you go that route (pun intended) you might consider using something like libuv [2].

[1] https://github.com/ashtonjamesd/lavandula/blob/51d86a284dc7d...

[2] https://github.com/libuv/libuv

By ashtonjamesd 2025-10-0914:52

Thank you for the feedback, it is appreciated!

I did intend to implement parallelization as a later feature so it's good to bring it up.