Re: [racket-users] Re: Efficient & "nice" communication mechanism between Racket and other languages
For youpatch.com my colleague and I used a "quasi-microservices architecture" to get my Racket, his Python, and our JavaScript to work together, using JSON and HTTP. Starting out with a JSON and HTTP would give you a baseline, and then swapping in other formats and transport mechanisms could allow for informative benchmarking. Dan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Efficient & "nice" communication mechanism between Racket and other languages
A hot-take brain-dump: Seems like two aspects: What and how. (The serialization format and the communication method.) What: The correct answer is s-expressions. :) Maybe EDN. OK, OK. A more agnostic answer is JSON -- it has flaws, but it's widely supported among languages, and "everything is a dictionary" is a decent first approximation for many things. If people think plain text is a problem not a feature, (a) they're wrong :) but (b) there are things like BSON and Protocol Buffers as David mentioned. How: For things that fit a request/response model, HTTP has already figured out a lot of stuff you might not want to. Also keep in mind it even supports things like partial random-access (Range headers) and memoization (ETags). If request/response isn't a good fit, there's also RFC 6455 aka WebSockets? (https://pkgs.racket-lang.org/package/rfc6455) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: Efficient & "nice" communication mechanism between Racket and other languages
On Thursday, September 7, 2017 at 11:56:37 PM UTC-4, Jack Firth wrote: > On Thursday, September 7, 2017 at 9:11:47 AM UTC-7, Brian Adkins wrote: > > I'm considering having a group of programmers create micro-services in > > various programming languages to be glued together into a single > > application. I would like a communication mechanism with the following > > characteristics: > > > > * More efficient than HTTP > > Unfortunately Racket doesn't have an HTTP/2 implementation, or I would > recommend that. Could you elaborate on your efficiency requirements? It's > possible a proxy that handled HTTP/2 connections could work for you and I > suspect that would be much simpler than trying to make your own APIs atop a > lower-level messaging protocol like ZeroMQ. This is more of an experiment in a ridiculously distributed application to allow people to use their favorite programming language w/o a shared VM such as JVM, CLR or Erlang. So, ideally, the latency would be as low as possible. For a toy experiment, HTTP would be fine, and would probably even perform "reasonably" well with a small load, but I was curious about how far things could be pushed with respect to micro services. It may be that a simple TCP protocol is the way to go with a simple serialization mechanism. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: Efficient & "nice" communication mechanism between Racket and other languages
On Thursday, September 7, 2017 at 9:11:47 AM UTC-7, Brian Adkins wrote: > I'm considering having a group of programmers create micro-services in > various programming languages to be glued together into a single application. > I would like a communication mechanism with the following characteristics: > > * More efficient than HTTP Unfortunately Racket doesn't have an HTTP/2 implementation, or I would recommend that. Could you elaborate on your efficiency requirements? It's possible a proxy that handled HTTP/2 connections could work for you and I suspect that would be much simpler than trying to make your own APIs atop a lower-level messaging protocol like ZeroMQ. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
