cel-spec VS wrappers

My employer uses a combination of Protocol Buffers (for the config schema definition) and Bazel/Starlark (for concrete instantiations). Configs are validated at build time and runtime using CEL (https://github.com/google/cel-spec).

The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate. https://github.com/google/cel-spec

Looks like Google invented a specification for a simple "expression language." -> https://github.com/google/cel-spec/blob/master/doc/langdef.md. Writing the expressions feels like writing Java, C++, Go, or TypeScript code. Google then released C++ and Go versions of this langauge as a library.

https://github.com/google/cel-spec unfortunately, it's in Go or C++. Of course I can write a binding to them. But is there any other similar that you would know of for Java? My other course of action would be to offload computation to another service using this library in Go, or Jsonnet or Open Policy Agent/Rego based evaluation, which I'd prefer not to. Executing JS in Java via Nashorn also an option but it'd be heavy weight.

Having a standard way to share expressions does seem quite useful, especially when it's multilingual.

[0]: https://github.com/google/cel-spec

There's more information about CEL and its specifications here

Especially when dealing with more complex match rules, I personally much prefer Caddy's matchers over building some weird-ass if constructs in Nginx. It also supports CEL for request matching, giving you access to extremely powerful logic, if you need it.

I used one of their open source work in a project: https://github.com/supabase/wrappers

It’s appreciated since SaaS on AWS is a no-no in my field.

I’m currently playing with PostgreSQL, foreign data wrappers, and pgrx rust extensions. My development experience has been surprisingly smooth and enjoyable.

My main issue is that joins will be processed locally, so all the foreign data will be fetched before the join happens. But otherwise basic CRUD is easy.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

https://github.com/pgcentralfoundation/pgrx

https://github.com/supabase/wrappers

However, considering the emergence of Supabase wrappers, it might be more beneficial to develop a walkthrough focused on creating Rust-based wrappers. This way, the community can start building a variety of useful wrappers (really plugins).

We're experimenting with including tables connected to external data sources using Supabase Wrappers https://github.com/supabase/wrappers as a way to link external APIs into the GraphQL schema but that work is in an early stage. That approach would be limited to the Stripe, Firebase and S3 for now though

This would be an ideal use case for a postgresql foreign data wrapper. See more here: https://github.com/supabase/wrappers/

> On a sidenote, is not the wrappers for Airtable, BigQuery and ClickHouse opensourced? Or why did they skip that column in the second table?

All of the wrappers are open source. You can see the source for the Airtable, BigQuery, and ClickHouse wrappers here https://github.com/supabase/wrappers/tree/5fac8afb62e6e8362b...

The `self-hosted` column is only missing from the "under development" wrappers in the blog post's table because those are not production ready and shouldn't be self hosted (yet).