Define a plugin system that can work for any data source

[benmccann]

There are many other data sources that might be valuable to add such as REST, RDBMS, file system, etc. I imagine a project could use multiple - even on the same page.

[ConProgramming]

Thanks for raising this issue! Yep, I wrote the internal code for processing dataSources to be pretty extensible, but the problem is every dataSource would need to end up returning data in a way that can be parsed by Jungle into the GraphQL data layer, for other pages to easily use. I did this with the dir/markdown dataSource, but I'm not sure if the same can/should be done for databases, etc. The goal is to have an extensive plugin ecosystem that conforms to the community, so I wanted to wait until the community brought up the discussion to implement plugins.

But yes, I agree, it should definitely be easy to connect the Jungle GraphQL data layer to a REST api, or a RDBMS, or whatever else with any other plugins. Any thoughts on how you would want to be able to use data sources?

Might be interesting for us to do something similar to what Gridsome did with source plugins.

[jokin]

you cand get a graphql layer for almost everything, for postgresql you can use postgraphile embedded and read from a database easily. There is even a graphql plugin for wordpress, so you can in theory use wordpress admin to edit your content and show on junglejs. I don't know if junglejs system is very different from gatsby one, but if similar, almost any source that you can use on gatsby (which are a lot) could theoretically be used on junglejs, that would be huge, as you can us enetlify cms, graphcms, strapi, etc as sources.

[ConProgramming]

@jokin I agree, actually more so Jungle should be able to work for a GraphQL layer of everything as long as we or some one in the community makes a plugin for it. Right now I'm using graphql-compose, to turn JSON data from, as of now, raw JSON and markdown files into a schema. If I remember right, Gatsby and Gridsome also use graphql-compose.

Also, if NetlifyCMS works like Forestry and saves markdown files in your git repository, they'll already work with Jungle 👍.

[benmccann]

I'm not that familiar with the other implementations like Gridsome, but I wonder if it'd be possible to find one we like and adopt their API for the plugin layer at least so that there's already a whole plugin ecosystem available for use

[ConProgramming]

Ooh that'd be a good idea... I'll check out both Gatsby's and Gridsome's plugin interfaces and check if it'd be possible to use their plugins with Jungle

[benmccann]

Here are the docs for Gridsome data store plugins and Gatsby source plugins for reference

[stordahl]

I want to bump this issue. Would love to build a plugin for Sanity!

[ConProgramming]

I want to bump this issue. Would love to build a plugin for Sanity!

I'd love to see a bunch of plugins yeah! I think the debate is over to specify our own api or to adopt the api of gatsby/gridsome somehow... @HendrikRoth has done some work for plugins in the TS rewrite too I think!

[HendrikRoth]

We worked on a uniform plugin interface for junglejs. At the moment we are waiting for the next coming svelte-next release with snowpack integration, where we hope we can write a middleware for to make things way easier :-)

[teds31]

Has the directive changed since SvelteKit is no longer using snowpack and is now using vite?

[ConProgramming]

I'm assuming SvelteKit is going to still make it easy to integrate different build processes, but of course there's no way to know. As of now tho, the directive is still just to see how SvelteKit changes the future of Svelte before we take any big steps

[benmccann]

I'm not sure what you mean by integrating different build processes. As for how to know - I'm happy to share details ;-) Basically SvelteKit uses Vite as the build tool so you should hopefully be able to do anything you can do with Vite

[ConProgramming]

Ah great. And by "different build processes" I meant "adapters." I forget the word y'all used for it haha. I played around with SvelteKit back when it first was sneakily put on npm (back in October?) but I haven't taken a look since... I'm thinking though that JungleJS might be able to basically function as just a SvelteKit adapter though?

[benmccann]

It's doubtful to me that you could use SvelteKit as a static site generator except for small sites or that it'd be a good fit for JungleJS. Most static site generators have a phase up-front where they get the data necessary to build the site to avoid refetching data shared between pages. SvelteKit does not operate this way. It can pre-render pages but would build each page independently and refetch any data shared between pages

[ConProgramming]

The GraphQL schema makes caching pretty easy so I'm sure some sort of cache-first approach could make sure data isn't refetched between pages. Or even a separate process running alongside SvelteKit, fetching data before a junglejs adapter uses it... Or you may be right in that SvelteKit might just not be the way to go here, but I guess we don't know till I can work with it ;)

[benmccann]

Take a look https://github.com/sveltejs/kit/ 😉