That's great! I'll need to have a look at Algolia as well, and hooking it up with Contentful is the next step. Ah testing, could you maybe elaborate a bit on what and how you test? It's something I've been actively ignoring so far and I know that's not good.
But I agree, the JAMstack is an excellent concept and makes projects a lot of fun to work with. I'm looking forward to integrate it more in my professional environment.
We are also looking into using nightwatch / phantom / casper (we aren't fully committed to one of these yet so its up for debate) to automate the testing of some our mission critical customer journeys through out website. The client has quite a large testing team which focus their testing mainly on the mobile app, but they haven't really had the website as part of their scope historically. Whilst this seems like a missed opportunity to utilise them as a resource for web testing, it is also actually leaving us with optionality. I would much prefer to have automated unit, integration and to an extent our pre-canned UAT tests. The human eye should really only be cast over some of the newer components we release, with everything else checking/failing before or during our build pipeline.
We created our initial site using graphQL, Gatsby and Markdown. The switch to Contentful instead of Markdown was a breeze when we had all of the graphQL queries already modelling what we needed.
Likewise. I’ve been working in a similar stack. It really is amazing to work with. Now, we’re just starting to use Netlify’s open source CMS which uses git to handle content versioning. Did you guys look at that at all before picking Contentful? I think Contentful looks awesome too, just curious if there were any pros/cons between the two.
I think there are a few nice perks, such as visualising the models you produce as well as the media library aspects. End of the day it felt a bit more friendly for the marketing guys to understand and use (They arent changing or configuring YAML). The developer team were happy to use either and I think if you are working with a pure dev team then there is no issue using Netlify openCMS, but where there are "business" users involved, the confluent UI proves to give the right level of abstraction away from coding (Yes even markdown files scares some people!). It also feels a lot closer to the traditional CMS for content creation, they like to see the layout and previews, images rendered before fully publishing etc.
We also found the pricing model at contentful to be really friendly, to set up a proof of concept and allow the business users to mess around creating their content with the benefits mentioned in the previous paragraph made it an easy sell when it came to moving into a small subscription. There's also the support model wrapped around all of this and since the content is served over multiple channels, the internal due diligence from service management and security teams forced our hand to an extent to keep away from a self hosted open source product.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Excellent post! I've recently been working through a JAMstack design with a client utilising the following architecture stack:
It's been utterly awesome to work with and really shows the power of the JAMstack.
That's great! I'll need to have a look at Algolia as well, and hooking it up with Contentful is the next step. Ah testing, could you maybe elaborate a bit on what and how you test? It's something I've been actively ignoring so far and I know that's not good.
But I agree, the
JAMstackis an excellent concept and makes projects a lot of fun to work with. I'm looking forward to integrate it more in my professional environment.We will be using Jest and enzyme for our basic testing. There's a nice overview of that here: hackernoon.com/testing-react-compo...
We are also looking into using nightwatch / phantom / casper (we aren't fully committed to one of these yet so its up for debate) to automate the testing of some our mission critical customer journeys through out website. The client has quite a large testing team which focus their testing mainly on the mobile app, but they haven't really had the website as part of their scope historically. Whilst this seems like a missed opportunity to utilise them as a resource for web testing, it is also actually leaving us with optionality. I would much prefer to have automated unit, integration and to an extent our pre-canned UAT tests. The human eye should really only be cast over some of the newer components we release, with everything else checking/failing before or during our build pipeline.
We created our initial site using graphQL, Gatsby and Markdown. The switch to Contentful instead of Markdown was a breeze when we had all of the graphQL queries already modelling what we needed.
Likewise. I’ve been working in a similar stack. It really is amazing to work with. Now, we’re just starting to use Netlify’s open source CMS which uses git to handle content versioning. Did you guys look at that at all before picking Contentful? I think Contentful looks awesome too, just curious if there were any pros/cons between the two.
I think there are a few nice perks, such as visualising the models you produce as well as the media library aspects. End of the day it felt a bit more friendly for the marketing guys to understand and use (They arent changing or configuring YAML). The developer team were happy to use either and I think if you are working with a pure dev team then there is no issue using Netlify openCMS, but where there are "business" users involved, the confluent UI proves to give the right level of abstraction away from coding (Yes even markdown files scares some people!). It also feels a lot closer to the traditional CMS for content creation, they like to see the layout and previews, images rendered before fully publishing etc.
We also found the pricing model at contentful to be really friendly, to set up a proof of concept and allow the business users to mess around creating their content with the benefits mentioned in the previous paragraph made it an easy sell when it came to moving into a small subscription. There's also the support model wrapped around all of this and since the content is served over multiple channels, the internal due diligence from service management and security teams forced our hand to an extent to keep away from a self hosted open source product.