devj

More excited about the service worker based build system being developed in the emberjs ecosystem. Check it out here - https://github.com/ef4/mho

And there's Amazon Ion too - https://amzn.github.io/ion-docs/

"Amazon Ion is a richly-typed, self-describing, hierarchical data serialization format offering interchangeable binary and text representations. The text format (a superset of JSON) is easy to read and author, supporting rapid prototyping. The binary representation is efficient to store, transmit, and skip-scan parse. The rich type system provides unambiguous semantics for long-term preservation of data which can survive multiple generations of software evolution."

OpenAPI 3.1 which was released recently, uses JSONSchema 2020-12 as the primary schema format. The incompatibilities has been completely resolved as of today.

OpenAPI 3.1 which was released recently, uses JSONSchema 2020-12 as the primary schema format. As a result, we can expect further consolidation of tooling, etc in the community.

## Changelog

The below changes are documented as part of the release notes.

### Additions

1. Introduced a new top-level field - `webhooks`. This allows describing out-of-band webhooks that are available as part of the API.

2. The Info Object has a new `summary` field.

3. The License Object now has a new `identifier` field for SPDX licenses.

4. Components Object now has a new entry pathItems, to allow for reusable Path Item Objects to be defined within a valid OpenAPI document.

5. Added the `jsonSchemaDialect` top-level field to allow the definition of a default $schema value for Schema Objects.

### Extended Functionality

1. Updated primitive types to be based on JSON Schema Specification Draft 2020-12. This now includes type null.

2. Lifted the restriction of allowing Request Body only in HTTP methods where the HTTP 1.1 specification RFC7231 has explicitly defined semantics for. While allowed in other methods, it is not recommended.

3. Added support to object type for spaceDelimited and pipeDelimited style values.

4. The Encoding Object now supports `style`, `explode` and `allowReserved` for multipart/form-data media type as well.

5. To enable better webhooks support, expressions in the Callback Object can now also reference Path Item Objects.

6. When using the Reference Object, `summary` and `description` fields can now be overridden.

7. The Discriminator Object can now be extended with Specification Extensions.

8. Added support for mutual TLS (mutualTLS) as a security scheme.

9. Used security requirements can now define an array of roles that are required for execution (and not only scopes for OAuth 2.0 security schemes).

### Changes

1. An OpenAPI Document now requires at least one of paths, components or webhooks to exist at the top level. While previous versions required paths, now a valid OpenAPI Document can describe only webhooks, or even only reusable components. Thus, an OpenAPI Document no longer necessarily describes an API.

2. Anywhere in the 3.0.0 Specification that had a type of Schema Object | Reference Object has been replaced to be Schema Object only. With the move to full JSON Schema support, $ref is inherently part of the Schema Object and has its own defined behavior.

3. Both `x-oai-` and `x-oas-` prefixes for Specification Extensions are now reserved to be defined by the OpenAPI Initiative.

4. `format` is now not validated by default.

### Breaking changes

1. The specification versioning no longer follows SemVer.

2. The nullable keyword has been removed from the Schema Object (null can be used as a type value).

3. `exclusiveMaximum` and `exclusiveMinimum` cannot accept boolean values (following JSON Schema).

4. Due to the compliance with JSON Schema, there is no longer interaction between `required` and `readOnly`/`writeOnly` in relation to requests and responses.

5. `format` (whether byte, binary, or base64) is no longer used to describe file payloads. As part of JSON Schema compliance, now contentEncoding and contentMediaType can be used for such specification.

6. Server Variable's `enum` now MUST not be empty (changed from SHOULD).

7. Server Variable's `default` now MUST exist in the enum values, if such values are defined (changed from SHOULD).

8. `responses` are no longer required to be defined under the Operation Object.

### Clarifications

1. Reworded the definition of OpenAPI Document to reflect that a document no longer must describe paths, but can describe either paths, webhooks, components or any combination of them.

2. Further updated Schema Object's description to take into account the latest draft, and the default use of https://spec.openapis.org/oas/3.1/dialect/base as the default OAS dialect.

3. Dropped the term RESTful APIs in favor of HTTP APIs.

4. Resolution of relative references has been redefined and clarified. Note there's a difference in resolution between Schema Object References and all others.

5. Modification of examples to improve them and provide context for new fields/objects.

6. Path parameter values cannot contain the unescaped characters /, ? or #.

7. Unified wording when values are URLs/URIs.

8. Reworded Path Item's $ref to take into account reference and component changes.

9. Minor text changes to improve consistency and readability.

10. Reworded "Schema Vocabularies" to "Schema dialects".

11. It is now clarified when path template expression may not have a corresponding path parameter.

12. A new section was added to address how to handle the `$schema` keyword (implicitly and explicitly).

Though we do not generate the entire server code, we do follow a spec first design paradigm for APIs as well as DB. We have adopted hexagonal architecture for our web framework and therefore, code generation is limited to fit in it. We use Starlette and SQLAlchemy.

Since Firefox has partnered with Amazon(SES) to filter spam, does it mean that Amazon can read our emails too?

How does datafusion based engine like this compare to timely/differential dataflow(naiad)?

PS: Im a rookie in this whole domain.. so any pointers would be really helpful.

CEL spec: https://opensource.google/projects/cel

JSONLogic - http://jsonlogic.com/

The discussion thread is related to a tool created by UBER: Piranha - https://eng.uber.com/piranha/

Sorry.. Forgot to mention that.

Yes insertion/deletion is required and the frequency may be higher. The exact usecase is that group membership is dependent on some conditions. We schedule this check every 15 minutes and based on it, we are adding/deleting the members.

I have a requirement of checking group membership wherein a group may contain > 10K members. Each member is an 8byte ID. Do you think Xor filter would be a better fit compared to Bloom here? Or am I looking at it the wrong way? Thanks.

Try jsonata.org

Earlier post here - https://news.ycombinator.com/item?id=21779191

How does it compare with CouchDB Replication protocol - https://docs.couchdb.org/en/stable/replication/protocol.html?

# Fast, portable, non-Turing complete expression evaluation

Common Expression Language (CEL) is a non-Turing complete language designed for simplicity, speed, safety, and portability. CEL is designed to be evaluated without a sandbox, making it ideal for use within latency critical applications.

## Features

  - Familiar C-like syntax common to C++, Go, Java, and TypeScript.

  - Gradual typing with first-class support for Protobuf and JSON types.

  - High performance evaluators in C++ and Go with a rich set of standard operators.

Google uses CEL as the expression component of IAM and Firebase security policies, as well as within Istio Mixer configs.

Would like to know more on how its a good fit for database schemas? Does anybody here use any DSLs for database schemas? If yes, what and why?

Can Excel be categorised under Visual Programming?

Thanks for your reply. Would be really helpful if you can share the following:

1. Size of the CloudKit cluster and the number of RecordLayer instances. A ratio would also be enough to get an approx. idea.

2. How metadata changes involving field data type are being handled?

3. How are relationships and therefore, foreign keys handled? Are any referential actions like cascading deletes supported?

Few doubts:

1. Any reason to write it in Java instead of C, C++, Rust, etc?

2. Any reason to use Protobuf instead of Flatbuffers, Avro, etc?

3. Can FoundationdDB be used with Apache Arrow?

To all Rustacenas who are running Rust in production, would you create an "Effective Rust"?

Do you think markdown-it token stream(https://github.com/markdown-it/markdown-it/blob/master/docs/...) may serve the same purpose?

For JSON querying, checkout JSONata(http://jsonata.org/ - Inspired by the location path semantics of XPath 3.1) . It was created by Andrew Coleman(Part of W3C XML Query WG).

Noob question: Which data serialisation format is used to represent models? Are there any standardisation efforts being undertaken by the community?

Wow.. Which client language are you using?

How is Vegalite different from Muze?

Even I had the same question - https://news.ycombinator.com/item?id=17916769 .

I'm aware of the following options:

1. PouchDB(CouchDB HTTP protocol) or RxDB

2. DexieJS(Indexed DB Wrapper)

3. Mozilla LocalForage(Indexed DB Wrapper)

4. OrbitJS(Indexed DB Wrapper using JSONAPI)

5. Google Lovefield(Relational equivalent)

6. GunJS

7. NanoSQL

Would love to hear from somebody with a production exp. in these technologies.

Agreed. But if lot of developers are using REST for CRUD, then it definitely means that most of the developers desire a CRUD way of server interaction.

Any solution?

How is it different from Pulumi(https://www.pulumi.com/)?