Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions.

However, our current use-case is that we want to get a job done, and not creating a web-framework.

1. For many things the docs are missing, or inconsistent, or wrong. So, it's pretty hard to make your way through it. Or you just start reading the code and reverse engineer vibe. => We are waisting a lot of time.

2. There are many inconsistencies / half-done implementations in vibe. Again, this makes it hard to find out what works, what doesn't or which parts behave differently. => Costs a lot of time.

3. Vibe can't handle GET & POST on the same URL... and the bad thing is, the later route will just be ignored, so you don't get any hint or crash. The docs don't mention this clearly. => We waisted a lot of time to find out, that this doesn't work.

4. Vide uses an own JSON type, not the standard one. We don't understand why, this just makes things much more complicated and one has to mess around with this.

5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary.

So, overall... compared to other web-frameworks we know, there are many pitfalls which just cost a lot of time... We think it's a good base, but there needs to be much less magic, much better docs, much less complexity.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary.

given an HTTPServerRequest req,
req.bodyReader.readAll for binary data and .readAllUTF8 for text.

On Thursday, 1 October 2020 at 06:39:39 UTC, mipri wrote:
> On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
>> 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary.
>
> given an HTTPServerRequest req,
> req.bodyReader.readAll for binary data and .readAllUTF8 for text.

thanks. that was tough to find from https://vibed.org/api/vibe.core.stream/InputStream (because it's located and thus documented in the helper module https://vibed.org/api/vibe.stream.operations/). a link from InputStream to vibe.stream.operations would be super-good.

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> 3. Vibe can't handle GET & POST on the same URL...

we solved this one as well: fortunately (and: of course) vibe can handle this.

what lead us to believe otherwise, was that, unfortunately, one of the handlers crashed (effectively due to a `cast(JSONValue)` of a `Json.Undefined`), without any visible error output; and the only visible error was a "no route matches path" output from vibe.

sorry for the confusion.

On Thursday, 1 October 2020 at 08:24:42 UTC, ab wrote:
> On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
>> 3. Vibe can't handle GET & POST on the same URL...
>
> we solved this one as well: fortunately (and: of course) vibe can handle this.
>
> what lead us to believe otherwise, was that, unfortunately, one of the handlers crashed (effectively due to a `cast(JSONValue)` of a `Json.Undefined`), without any visible error output; and the only visible error was a "no route matches path" output from vibe.
>
> sorry for the confusion.

did you run your app with `--vvvv`? it usually logs stuff like this there then.

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:
> Hi, we are currently using vibe.d for a prototype and I want to post some experiences. I know one shouldn't only address the problems but provide some solutions.
>
> [...]


I've been in a similar position once... when it slows you down. Vibe could stay simple and break things down into separate packages.

The docs is also a major issue. But try filling issues like these on the repo.

On Thursday, 1 October 2020 at 06:32:23 UTC, Robert M. Münch wrote:

> 4. Vide uses an own JSON type, not the standard one. We don't understand why, this just makes things much more complicated and one has to mess around with this.

Because standard implementation worse?

>
> 5. One can't access the raw HTTP request body, things must be go through Vibe's JSON parser. To get access to the raw body, a lot of workarounds are necessary.

Can you create PR?

On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote:
> Because standard implementation worse?

What do you mean with "worse"?
In my experience std.json is a very thin implementation of the JSON spec - without/very low "magic". IMO this is what one wants in a std lib. Its a good starting point for further simplfication wrappers or framework specific magic (what vibe actually do, if i am not mistaken

On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:
> On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote:
>> Because standard implementation worse?
>
> What do you mean with "worse"?

It's said to be pretty slow…

On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" <desisma@heidel.beer> wrote:

> On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote:
>>  On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin
>>  wrote:
>>>  Because standard implementation worse?
>> 
>>  What do you mean with "worse"?
> 
> It's said to be pretty slow…

Well, then it should be fixed... it doesn't make sense to spread N version because everyone things, A or B is not fitting for such a code framework.

And, this argument sounds like pre-mature optimization. Who has a real life use-case where the std lib JSON thing is too slow? By how much?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster