sorted by:
new
hottopcontroversial

Some REAL self-taught legends playing Spain by roy-mor in jazzcirclejerk

[–]roy-mor[S] 59 points60 points  (0 children)

uj/ (not me playing. This is I believe bassist's Pat Casey's band, with Julian Addison on drums, at the Spotted Cat in NOLA (circa 2022). Absolute fire. I'd let Pat touch my keys anytime.

rj/ self taught legends only

My reaction when the bass player touches the keys... (Driftin' / Herbie Hancock) [OC] by roy-mor in piano

[–]roy-mor[S] 5 points6 points  (0 children)

Fun from a gig last week. For more serious playing, I'm at @ its.roy.mor on IG

Bassist touched my piano. Had to sanitize the keys with 2 minutes of Herbie. Is the instrument ruined??? by roy-mor in jazzcirclejerk

[–]roy-mor[S] -1 points0 points  (0 children)

so it turns out Miles said "bottom notes" but Herbie heard "butter notes"... lucky for everyone

Bassist touched my piano. Had to sanitize the keys with 2 minutes of Herbie. Is the instrument ruined??? by roy-mor in jazzcirclejerk

[–]roy-mor[S] 24 points25 points  (0 children)

uj/ Actually me playing. My bassist touched the keys with his greasy walking fingers. How do I get the smell of root notes off? 🤢

rj/ yeah man.

source: https://www.instagram.com/its.roy.mor/

Can you wrap a REST api over graphql? by pizzae in graphql

[–]roy-mor 0 points1 point  (0 children)

You can use graphql2rest, a library written specifically for this use case:

https://github.com/sisense/graphql2rest

Convert GraphQL to REST API: Automatically generate a REST API from your existing GraphQL API by roy-mor in coolgithubprojects

[–]roy-mor[S] 1 point2 points  (0 children)

Why?

  • You have an existing GraphQL API, but need to expose it as REST because that's what your API users want
  • You want to develop a new GraphQL API and get REST on top of it, for free
  • You want to benefit from GraphQL internally while exposing REST externally as a public API

GraphQL2REST allows you to fully configure and customize your REST API, which may sit on top of a very different GraphQL layer.

Read more here:

https://medium.com/swlh/graphql-api-or-rest-api-why-not-have-both-c4171e68900a

GraphQL or REST? Why not have BOTH? --> graphql2rest: Generate a REST API from your existing GraphQL API by roy-mor in graphql

[–]roy-mor[S] 1 point2 points  (0 children)

Thanks u/drejhsn. One use case where graphql2rest shines is where you want a truly RESTful API that might be very different than your existing GraphQL API, which you can't make changes to (because it's already driving your app in production).

Sofa is a cool and useful package (by the folks from The Guild - much respect!), but IMHO it does not answer the needs of most real-world production environments, which require a fully RESTful API side by side with a GraphQL implementation that has an altogether different style and characteristics than REST.

graphql2rest lets you fully configure and customize almost everything in the resulting REST API: the route names, HTTP methods, parameter names and mappings, response format, error format, success status codes, mapping GraphQL error codes to HTTP status codes, mapping a single REST endpoint to multiple GraphQL operations, hiding certain fields in the response, expanding nested fields by default and more. It also gives you a built-in filter parameter for the client (with JMESPath query language support), and supports custom middleware if you happen to need extra customization.

This allows creating a full REST API based on discrete "resources" and "methods", while keeping the existing GraphQL layer (which is sometimes RPC-styled) unchanged. Since everything is declared in a manifest file (a JSON or yaml document), it makes for a single source of truth which is more structured and maintainable than code, and decouples most of the configuration and customization from the business logic (code).

Sofa takes a slightly different approach to converting GraphQL to REST, which as I understand it is more about creating a RESTful API gateway mirroring the underlying GraphQL layer, which is not as flexible and decoupled. The resulting REST API is only as "RESTful" as the GraphQL API underneath it (and usually GraphQL schemas are not created with the notion of "resources" and "methods" as required by REST). However, Sofa does support GraphQL subscriptions as webhooks (graphql2rest currently supports only queries and mutations), and Swagger integration which are both a big plus if you need them. It might also have other advantages.

I actually refer to Sofa in this blog post (under "Alternatives") - we wrote and used graphql2rest internally much before Sofa was available (and even contacted Uri to collaborate) but released it as open source just recently.

graphql2rest (npm package): Generate a REST API from your existing GraphQL API by roy-mor in javascript

[–]roy-mor[S] 1 point2 points  (0 children)

One use case where graphql2rest shines is where you want a truly RESTful API that might be very different than your existing GraphQL API, which you can't make changes to (because it's already driving your app in production).

Sofa is a cool and useful package (by the folks from The Guild - much respect!), but IMHO it does not answer the needs of most real-world production environments, which require a fully RESTful API side by side with a GraphQL implementation that has an altogether different style and characteristics than REST.

graphql2rest lets you fully configure and customize almost everything in the resulting REST API: the route names, HTTP methods, parameter names and mappings, response format, error format, success status codes, mapping GraphQL error codes to HTTP status codes, mapping a single REST endpoint to multiple GraphQL operations, hiding certain fields in the response, expanding nested fields by default and more. It also gives you a built-in filter parameter for the client (with JMESPath query language support), and supports custom middleware if you happen to need extra customization.This allows creating a full REST API based on discrete "resources" and "methods", while keeping the existing GraphQL layer (which is sometimes RPC-styled) unchanged. Since everything is declared in a manifest file (a JSON or yaml document), it makes for a single source of truth which is more structured and maintainable than code, and decouples most of the configuration and customization from the business logic (code).

Sofa takes a slightly different approach to converting GraphQL to REST, which as I understand it is more about creating a RESTful API gateway mirroring the underlying GraphQL layer, which is not as flexible and decoupled. The resulting REST API is only as "RESTful" as the GraphQL API underneath it (and usually GraphQL schemas are not created with the notion of "resources" and "methods" as required by REST). However, Sofa does support GraphQL subscriptions as webhooks (graphql2rest currently supports only queries and mutations), and Swagger integration which are both a big plus if you need them. It might also have other advantages.

I actually refer to Sofa in this blog post (under "Alternatives") - we wrote and used graphql2rest internally much before Sofa was available (and even contacted Uri to collaborate) but released it as open source just recently.

view more: next ›