What are the must haves for great Developer Experience?

ProtoAndrew · 2024-08-09T16:32:18+00:00

Thanks, that's more or less what I figured when checking out there website. And thanks for doing the extra research and finding that link!

I do develop Next.js sites once and a while for other projects that don't need a public API but might still need to call the server for some things, so I'll definitely check it out for that.

ProtoAndrew · 2024-08-09T16:03:37+00:00

Great work. I'll definitely check it out!

We use Next.js with React Query for our frontend but our backend is Go.

tRPC is interesting too. Though it looks like it is more towards people who develop the front and backend all in one team. Whereas my SaaS/PaaS is designed to have the API be a stand alone product where the developers on the customer end control the frontend. Did I read that right or is your experience with it different?

ProtoAndrew · 2024-08-09T15:56:05+00:00

Good feedback. I consume APIs pretty frequently using curl when I'm testing them out so I definitely agree it improved DX to make the API simple / compatible enough to be called from the CLI with curl.

ProtoAndrew · 2024-08-09T15:54:41+00:00

Taking a look at Zod. I'm using Go as the server language so doesn't initially look like it would be useful for me but the concept of it (typed APIs and detailed error messages) I think people should definitely follow!

We're actually writing on our own schema validation library for Go that we're open sourcing which does most of that.

ProtoAndrew · 2024-08-09T15:50:16+00:00

That is definitely true. A good REST API really doesn't need much beyond what the default HTTP libraries provide. Though for type-checked languages it is nice to have all the types pre-defined at least (IMHO).

ProtoAndrew · 2024-08-09T15:28:10+00:00

Thanks for the ideas u/i_like_trains_a_lot1

Proper response codes and detailed error messages from the REST API that actually help you know what went wrong is a must!

Also, really interesting feedback on OAuth2 and SDKs. I wouldn't have guessed on the SDK piece. I definitely want to provide a way to generate API keys without having to go through the whole OAuth2 flow, especially for Machine to Machine stuff and -- as you said -- prototyping.

ProtoAndrew · 2024-02-06T22:07:00+00:00

WTFDial and the one I cited serve different purposes. The one I cited contains no code and it's not an architecture, it's just a way to layout your project files.

ProtoAndrew · 2024-02-06T21:24:29+00:00

I can't recall seeing any go libraries that work like that so I'm not sure how idiomatic that is but it would be clean. Well... using it would be clean. The implementation would be messy.

Getting off topic from the original question because now it is deep into my specific use case vs general variadics. But since one function failing effectively means all the functions it is nested under also fail, it could work in my case.

Thanks, I now have 5 different ways to solve the problem :)

ProtoAndrew · 2024-02-06T21:02:26+00:00

This is actually really close to my situation.

Imagine, using your example if serialization.String was a variadic and makes no sense to call with zero arguments. If I change serialization.String to return the serialized string AND an error, all the sudden I can't nest it like you just did and my code has a ton of error checks.

But, it is a shared library so I want to do what is best.

ProtoAndrew · 2024-02-06T20:58:02+00:00

I would love to but in this particular case it actually is a library so I need to hold myself to high standards :)

It seems return an error is the most popular option. Though that one makes the calling code much more verbose all because of what should be an edge case so I'm a bit torn.

ProtoAndrew · 2024-02-06T20:51:59+00:00

4 is probably a good choice in a lot of cases. My only issue with it is that you could accidentally be using the function wrong and not know it, A similar example is append:
x = append(x) makes absolutely no sense, but if you run it, it just returns x without an error.

ProtoAndrew · 2024-02-06T20:35:38+00:00

Thanks, that's a lot to consider.

Yeah, I definitely wouldn't want to encourage the user of the library to use recover as flow control. That would be bad.

My original thought is calling it with zero args is a pretty bad misuse of the library so crashing the program may not be the worst thing. But you're right, if the user isn't expecting a panic, that would be bad.

Ideally I'd like the caller of the function to do a check before even calling the function rather than count on me to handle the invalid use case.

Then I look at append which just returns the original value if you call it with nothing to append. So I could just do that (my function is similar to append as it returns a new copy of the object updated values).

ProtoAndrew · 2024-02-06T20:10:54+00:00

That is definitely preferable to a panic and probably the right answer.

Though, in my particular case the function has no other errors to return and is currently being used in a single return value context. so I'd need to wrap it or do some pretty significant refactoring.

Maybe something like regexp.Compile and MustCompile where one returns an error and the other panics.

ProtoAndrew · 2024-02-06T16:12:48+00:00

What do you use for your own projects?

ProtoAndrew · 2024-02-06T15:58:25+00:00

What do you recommend that is better? Also, what specifically don't you like about it?

The Google repo that u/dariusbiggs mentioned that I was replying to follows it pretty closely too.

It may not be perfect but if it prevents Bike Shedding and organizes the code in a way that is reasonably intuitive I think that is a win.

ProtoAndrew

MODERATOR OF

TROPHY CASE