Location: Montréal, Québec, Canada
Remote: Yes, (hybrid in Montréal)
Willing to relocate: No
Technologies: Scala / Java, Typescript / Javascript, Python, Rust, PostgreSQL / MySQL / SQLite, AWS / GCP, Terraform
Résumé/CV: https://davidfrancoeur.com/resume.pdf
Email: [email protected]
Senior Software Developer with extensive experience with Scala (and Java), Typescript (and Javascript) and Python. Very interested in functional programming languages like Haskell and Nix, but also low-level system programming like Rust.
Not an expert, so I could be wrong, but my understanding is that you could just copy those bytes directly from the wire to your memory and treat those as the Arrow payload you're expecting it to be.
You still have to transfer the data, but you remove the need for a transformation before writing to the wire, and a transformation when reading from the wire.
I'm working in a small/medium business in Montreal, Canada. I've been hear for almost 3 years and AFAIK no body here takes stimulant.
Of course I might be wrong, but I know a lot of these people well enough to call them my friends and I have not see anyone taking stimulant nor overheard anyone talking about their consumption.
As you know, there are many plugins to do authentication in Kong. We started with jwt, then a coworker decided that we needed a more flexible approach so he basically forked the jwt plugin to add stuff for our needs. It quickly became confusing and hard to maintain.
When we tried to introduce a new feature (tokens similar to what Github offers with personal token, that is a revocable token with a given set of permissions), we had a rough time.
In the end, the decision to fork the plugin was maybe not the good one and the decision to bring the token feature into this plugin were maybe not the right one. But still, working in the plugin code was unpleasant in my opinion.
By the way, keep up the good work, it's a solid piece of software!
Disregarding the article completely, I'll share my opinion on Kong because we use quite a bit at my workplace. We use an old version (0.9.x as of right now). The things I shared below might not be true anymore in new versions but I can't tell and are regarding the plugin system.
IMO, the idea of taking things like authentication, rate limiting, etc in a proxy is a wonderful idea (https://2tjosk2rxzc21medji3nfn1g-wpengine.netdna-ssl.com/wp-...). So in theory, the approach Kong takes is wonderful, but I think the implementation is not so much.
Kong is layer over nginx and uses lua as a scripting language to add all sorts of stuff. Quickly, you reach the limit of the plugins capability so you think, well, I will write my own plugins. Well, to me it was a very unpleasing experience. I found that the thing was hard to test and hard to maintain. Maybe my criticism is more lua than Kong but since Kong relies heavily on lua, there is not much I can do.
There is also magic happening. You declare a schema.lua files to configure the store to hold your data. Then automatically you've got a DAO interface available with a bunch of method on it to work with the store. You don't know what methods are available or what arguments should be passed into these functions.
Anyway, this is my take after spending quite a few hours working on home made plugins in lua for Kong.
In the end, I'm glad Kong is open source and it's a great piece of software. It helped us reduce our applications complexity but make sure you don't start to shift to much logic into it because the plugin system can be hard to work with.
Suppose you build a STREAM or TABLE from a topic and assume a field in the event is `id`. Later on, you introduce an update to this event where where your replace `id` by `user_id`, how is KSQL reacting?
Senior Software Developer with extensive experience with Scala (and Java), Typescript (and Javascript) and Python. Very interested in functional programming languages like Haskell and Nix, but also low-level system programming like Rust.