
Silicon: C++14 web framework - api
http://siliconframework.org/blog/silicon-0-1.html
======
jstimpfle
I've seen many web frameworks where the design is centered around URL+Method
dispatching (routing). Many frameworks also play overly clever type system
tricks in the dispatching code, just so the intro looks really short and
sweet.

Having developed two or three nontrivial web applications myself, I don't
think routing is a substantial part of web application design. A framework
which focuses on routing will probably be suitable mostly for small one-off
applications. This approach has in fact lead to significant boilerplate in my
routing endpoints. The boilerplate would probably not have amassed so
naturally if I had first implemented the actual functionality as data or
streaming interfaces.

If the functionality is finished, a custom integration with HTTP should not be
more painful then integrating with a framework. Furthermore, the
implementation can be accessed with an interface other than HTTP (testing,
internal scripts...)

------
reubenmorais
The hello world example takes 2.5s to compile on a 2.6GHz i7 + SSD. Adding 9
new routes bumps the compile time to 4.5s. 30 routes = 10s compile time. Seems
like this would get out of hand quickly for any moderately complex project.

Other than having to deal with complex templates, I personally wouldn't choose
this for web development because the advantages of the strongly typed routing
are dwarfed by the dangers of writing C++, especially when alternatives like
Rust exist today if you really need the low level performance advantages.

~~~
matt42
Indeed, compile time is a currently a problem for API with a large number of
routes. It'll probably get better with the C++17 Module TS.

What do you mean by the dangers of writing C++?

~~~
reubenmorais
I mean the memory safety pitfalls of C and C++, mostly.

~~~
matt42
You can write Silicon APIs without the use of any pointer, which save you from
most of the segv you can get with these languages.

------
KAdot
That's how the operator overloading abuse looks like.

------
matt42
Author here. Questions are welcome.

~~~
reubenmorais
1\. Why C++?

2\. Why the complex/unfamiliar DSL?

3\. The Boost dependency (through iod) is not documented on the website. Might
want to mention that.

~~~
matt42
Here are my answers on the reddit discussion:

1\. Why C++?

There is advantages (and disavantages) of using C++. There is situations where
loosely typed languages may be better but there is certainly lots of case
where C++ has many advantages. The problem is that today, it is pretty hard to
write web APIs in C++, this is why is not widely used, despite its
performances.

Hopefully, the standard finalized C++14 and I jumped on this opportunity to
take advantage of those new features (lambda, auto, variadic templates,...) to
write a zero-cost and robust web framework. Zero-cost because most of the
framework stack goes away at compile time, and robust because its static
paradigm enables the compile to detect most of the errors.

2\. Why the complex/unfamiliar DSL?

I found that in some case it really simplify the code and as long as the new
semantics is coherent, the user can get used to it quickly. I could have
chosen a non DSL approach, but it would have been more verbose, harder to
digest, and less similar to a real URL:

DSL: GET / _hello / _world / _id[int()]

Non DSL: GET.path(_hello).path(_world).url_param(_id, int())

3\. The Boost dependency (through iod) is not documented on the website. Might
want to mention that.

Thanks for noticing, I'll mention it.

~~~
jstimpfle
> The problem is that today, it is pretty hard to write web APIs in C++

What I think is needed is mainly a library for parsing and encoding of HTTP
requests and responses (I don't know what there is for C/C++). But in most
cases the CGI interface is good enough.

I think the model where some framework contains the main loop which drives the
application is deeply flawed because the implementation will strongly depend
on the framework.

The hardest part of creating an API is the _design_. This won't just go away
with yet another framework.

~~~
erichocean
> _What I think is needed is mainly a library for parsing and encoding of HTTP
> requests and responses (I don 't know what there is for C/C++)_

[https://github.com/nodejs/http-parser](https://github.com/nodejs/http-parser)

On the parser side, that's about as widely used/polished as you could hope to
see.

