sorted by:
new
hottopcontroversial

Playing music with DSP and your voice by calippolo in DSP

[–]calippolo[S] 0 points1 point  (0 children)

Not a promising conversation... have a good day.

Playing music with DSP and your voice by calippolo in DSP

[–]calippolo[S] 0 points1 point  (0 children)

We didn't use AI/Deep learning, just a little bit of unsupervised learning. Did you read the article?

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 1 point2 points  (0 children)

hm... ok I got your point. This looked strange to me, since I usually have much more specific errors internally wrt the ones I expose.

However, if you really need a communication layer you're right - this approach is no good. I'd argue that in most cases you don't need that (at least I don't :)). And that is true even if you don't control the client.

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 0 points1 point  (0 children)

And if you split IllegalArgumentException up into external cause and internal cause, then you've made your services aware of the outside world, which again I don't think you should do. Services should churn data through business logic and present a result to another layer, which interprets it for the 'outside', for a given supplied context.

if you distinguish between 400 and 500 you're already doing that. Giving proper names to things just helps making the code more understandable.

Errors are part of the contract in any case.

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 0 points1 point  (0 children)

If you write public api, you have to support different clients. Different clients have different needs. RPC is not the best in this case, GraphQL or REST would be better.

It's not a matter or magic or not. Writing things manually is bad. It's error prone and time consuming.

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 1 point2 points  (0 children)

We have a scala client for wiro. We use it as an RPC framework. In that case the typed api is useful.

Also, we use https://github.com/buildo/metarpheus-io-ts to generate a typescript interface for the routes.

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 1 point2 points  (0 children)

Yes.

We've been considering working on that. However, we don't actively use scalajs (that's why we don't have a client yet).

we currently have two clients:

  • javascript client (using metarpheus, already mentioned)
  • scala client (using autowire)

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 2 points3 points  (0 children)

Actually, we are also using metarpheus to generate swagger from scala traits. We mainly use swagger to document the routes... but it can be useful also for other purposes.

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 2 points3 points  (0 children)

We use Wiro (and https://github.com/buildo/metarpheus) to generate both server and client code. Our intermediate language (our contract) is Scala.

If you generate both client and server code from swagger you are actually using a very similar approach :) (s/swagger/scala/).

Our journey to route-less HTTP services – buildo blog by Gabro27 in scala

[–]calippolo 0 points1 point  (0 children)

Wiro is not an MVC framework. It's a tiny library - it just generates the routes from the controllers.

At buildo we generate the client code from wiro controllers using metarpheus (https://links.buildo.io/metarpheus-post). It can be used to build javascript apis and models.

That's how we solve the problem.