4 ms·

I was really hoping for a GraphQL API standard for mail before reading this. But this sounds good too.

thomasfoster96 8y ago
Reading through the JMAP website [0], I'm actually wondering whether whoever's behind JMAP has looked at GraphQL. There seem to be a lot of similarities (especially the "why not REST" section). [0] https://jmap.io/index.html https://jmap.io/index.html
- ForHackernews 8y ago
  I think Fastmail are the primary ones behind JMAP: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/
  - jasonmunro 8y ago
    Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)
- detaro 8y ago
  Work on JMAP likely started before GraphQL was publicly released.
Mailtemi 8y ago
Actually, Outlook GraphQL reusing the idea of batch JMAP calls. https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/beta/batch-outlook-rest-requests-beta https://docs.microsoft.com/en-us/previous-versions/office/of...
chrismorgan 8y ago
Understand that JMAP is an object synchronisation protocol. It’s most interested in the problems that are out of scope for GraphQL. You could have a variant of JMAP with GraphQL syntax and semantics, but there would be a fair bit of mismatch, for their purposes and focuses are quite different: JMAP is concerned with object identity and synchronisation, for what you might call thick clients (and JMAP Mail needs to be broadly IMAP compatible), while GraphQL is UI-focused, for what might reasonably be considered to be thin clients (not that they are logicless, but that they are very much focused on offloading burden to the server). I see no compelling case for a JMAP-like GraphQL thing. It could still be an interesting task to develop a object synchronisation protocol like the JMAP core on top of GraphQL.

Reading through the JMAP website [0], I'm actually wondering whether whoever's behind JMAP has looked at GraphQL. There seem to be a lot of similarities (especially the "why not REST" section). [0] https://jmap.io/index.html https://jmap.io/index.html

ForHackernews 8y ago
I think Fastmail are the primary ones behind JMAP: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/
- jasonmunro 8y ago
  Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)
detaro 8y ago
Work on JMAP likely started before GraphQL was publicly released.

Mailtemi 8y ago

Actually, Outlook GraphQL reusing the idea of batch JMAP calls. https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/beta/batch-outlook-rest-requests-beta https://docs.microsoft.com/en-us/previous-versions/office/of...

chrismorgan 8y ago

Understand that JMAP is an object synchronisation protocol. It’s most interested in the problems that are out of scope for GraphQL. You could have a variant of JMAP with GraphQL syntax and semantics, but there would be a fair bit of mismatch, for their purposes and focuses are quite different: JMAP is concerned with object identity and synchronisation, for what you might call thick clients (and JMAP Mail needs to be broadly IMAP compatible), while GraphQL is UI-focused, for what might reasonably be considered to be thin clients (not that they are logicless, but that they are very much focused on offloading burden to the server). I see no compelling case for a JMAP-like GraphQL thing. It could still be an interesting task to develop a object synchronisation protocol like the JMAP core on top of GraphQL.