Readit News* support for abstract apps, not only HTTP/web apps like heroku, let's say I want to deploy a SIP app
* support for HTTP/2 and potentially HTTP/3
If they do support these two I would say it's enough to be considered Heroku killer.
There is nothing in the protocol that mandates only 2xx status codes are parsable. Instead, the Content-Type pinpoints to the client what kind of content the body has, regardless the status code. And the content-type will most probably be what the client asked (if not, then the server announces that the response content is not subject to negotiation, something that you see rarely nowadays..)
In general I think this post reflects one of the mentalities that appeared around 10 years ago regarding HTTP APIs (another was the extreme hypermedia-driven APIs). But I really think nowadays we can do much better, we can deliver a practical API that works 99% of the times.
By the way in the latest HTTP RFC (RFC9110) status code 422 is finally officially defined (previously was part of webdav extention), which means that the war 422 vs 400 for validation and other semantic errors is over and we have a clear winner. But 200 vs 404 for something that was not found? Well that was has ended long ago I think..
I think the API Shale provides is pretty sane. I would probably use it in my next Ruby/Rails project. I don't like the fact that Nokogiri is included by default, it would be nice to declare a core type, and then bring in what you need (JSON, XML, YAML) as a different gem. But that's not a deal breaker for me.
I have created my own serializers in the past (SimpleAMS[1]) because I really detested AMS, no offence to AMS contributors, but AMS library should just die. Rails, and way more importantly Ruby, should come up with an "official" serializers/deserializers library that is flexible enough, rock solid and fast. For instance I had done some benchmarking among common serializer libraries [2] and AMS was crazy slow, without providing much flexibility, really (meaning, slowness is not justified). Others were faster, but were supporting only one JSON spec format (like jsonapi-rb). I am wondering where shale stands.
Another thing is that most serialization libraries seem to have ActiveSupport as a main dependency (not shale though) which I think is a bit too much, and actually has a performance hit on the methods it provides.
I really think that Ruby community can do better here ?
[1] https://github.com/vasilakisfil/SimpleAMS
[2] https://vasilakisfil.social/blog/2020/01/20/modern-ruby-seri... (scroll towards the end for benchmarks)
Reddit search isn't great (https://old.reddit.com/r/NoStupidQuestions/comments/lucx82/w...). But it's improving! (https://old.reddit.com/r/reddit/comments/t9nuaz/whats_up_wit...)
In the meantime, some of us still use Google to search Reddit, hence https://redditle.com
Or for some of us, because Google's results are increasingly filled with clickbait, "reddit" has been a cheatcode to navigate that. Redditle is for you too!
Is it the same as Googling "site:reddit.com"? Yes :D
Redditle also supports searching in a specific subreddit with "r/<subreddit>" e.g. "r/webdev guide to vue" would search in r/webdev.
GitHub repo - https://github.com/greentfrapp/redditle
Remote: Yes
Willing to relocate: Maybe
Technologies: Rust, Ruby, Javascript, PostgreSQL, ElasticSearch, Redis, AWS, Networks, APIs, Voip, SIP, SDP, WebRTC
Résumé/CV: https://vasilakisfil.social/public/FilipposVasilakis.pdf
Email: vasilakisfil@gmail.com
Among others:
* HTTP/REST APIs specialist, pure interest in networked services and optimizations
* Good knowledge of CAS/SAML/OAuth2 and related auth protocols
* Good knowledge of VOIP/SIP/SDP/RTP/WebRTC and related protocols
* Good knowledge of Distributed Systems theory, concepts & principles
Looking for a permanent role, but open to consultancy as well.
It's still convenient, but in really limited circumstances, AFAICT. This week I'll be going through the various Rust projects I maintain at work, seeing if there's useful places for let-else.