I'm writing a node CRUD app that requires a few CouchDB views (I'm using express and cradle).
I've got the node app itself controlled with git, but my DB views are currently uncontrolled.
What's the recommended way to put these under source control? I don't want to put the entire database (including data) under source control.
Take a look at couchapp, http://couchapp.org/. You can use that to push your version-controlled design docs to a database.
Maybe useful: also CouchApp may push some docs in db. For example, doc(s) of configure or demo. For that put file in folder '_docs' (the same level with 'lists', 'shows', etc.) in JSON format.
File: 'any-configure.json'
{
"_id": "any-configure",
"fieldA": "...",
"fieldB": "...",
...
}
As pointed, using couchapp could make it easier to work with design documents.
I have implemented a similar approach in a Java project, an example here and the class that manages these documents.
Related
I'm new to this frontend world, I have some knowledge on React and GraphQL and that's why I've decided to try and implement a test blog with Gatsby, as it seems pretty popular and easy to use.
I also wanted to get my hands into Material UI so I'm using this Gatsby starter : https://www.gatsbyjs.org/starters/Vagr9K/gatsby-material-starter
This starter seems to have included the integration with Netlify CMS, so I wanted to change that and start using Strapi CMS, so I can have the content there.
Any idea on how to do this?
There's a lot of stuff in your question, I'll try to answer it step by step if not, please let me know if you need more details of how to create pages, etc and I will update my answer to add more details if needed.
If you want to change your source from Netlify to Strapi you need to set it up in your gatsby-config.js, replacing gatsby-plugin-netlify-cms plugin for something like that:
{
resolve: `gatsby-source-strapi`,
options: {
apiURL: `http://localhost:1337`,
queryLimit: 1000, // Default to 100
contentTypes: [`article`, `user`],
//If using single types place them in this array.
singleTypes: [`home-page`, `contact`],
// Possibility to login with a strapi user, when content types are not publically available (optional).
loginData: {
identifier: "",
password: "",
},
},
},
Note that you'll have to install your desired plugins and remove the unnecessary in order to reduce the bundle package and improve performance when using starters.
The next step is to create pages from your source CMS (articles, posts, pages, etc) using GraphQL. Maybe this blog helps you. But as a short summary, you need to create queries in your gatsby-node.js to retrieve data from Strapi CMS and create pages using Gatsby's API.
The idea is the same as from your starters, however, instead of using gatsby-source-filesystem and using allMarkdownRemark in your page creation, you will use the object provided by Strapi CMS. You can check the queries and the available objects using gatsby develop and entering to localhost:8000/___graphql.
Keep in mind that you will always query static data (i.e: pre-downloaded data) from your multiple sources so when you run the develop command, the data is downloaded and accessible via GraphQL.
You can check for further information in its starter repository.
I have noticed that all the couchdb api helpers don't implement Mango query
I have found cradle started working on it, but seems they stoped implementing, nothing on docs about it.
https://github.com/flatiron/cradle/blob/master/lib/cradle/database/mango.js
Is there a good js api that supports mango find?
Secondary: Is there a reason why no one seems to be implementing mango query, why is everyone sticking to map/reduce?
Based on the comments give, I would like to clarify my question:
I know about pouch-find, but I presume this is for local storage or local instance of pouch that could be found in browser or nodejs, but I want to find a library that I can use to query couchdb database on the server.
I have found a temporary solution for now. Im using cradle with query function
ex:
db.query({
method: 'POST',
path: "/_find",
body: {
selector:{"_id": "settings/12345" },
limit:1,
//use_index: "_all_docs"
}
}
So to further explain my setup. Im using one couchdb per user. That db will sync to browser using pouchdb, I can use pouch-find to query that synced local copy (Is this correct?).
But then I have other couch databases that are not synced, that can be accessed by many users. To query these databases I use cradle with the above example.
You can find pouchdb-find here which is in development. If there is no api helpers for Mango Query yet, it's probably because it`s new altough cloudant had this query language since a moment.
I've been following along with the book Discover Meteor from https://www.discovermeteor.com/ and I have built the tutorial project called 'Microscope'
This uses iron-router and Meteor templating system to render out the front-end. I want to redo this project using famo.us for the front-end but I am unclear on how I to do so.
I am aware of a package called famono. mrt add famono. Using this package I can integrate famo.us and draw surface to the screen in a meteor project. It also allows you to render templates to the screen.
But I am confused on how to redo the project so the router - routes to render a famous surface with the data.
Also I am wondering if the templates will still be reactive.
If someone could provide insight on how to redo the 'Microscope' project to use famo.us on the front-end I would greatly appreciate it!
Thanks
UPDATE (to be more specific)
I have been trying to figure out how to integrate famous with templates and routing, and I have no clue how to do it.
I use iron-router to handle my routing which chooses which template and data to render like so:
Router.map ->
#route 'posts',
path: '/',
data: ->
Posts.findOne()
So this will load up the posts template with Posts.findOne() data.
But I know with famous I can generate surfaces from templates on the front end like so:
background = new Surface
template: Template.post
data: ??? (Posts.findOne()) ???
mainContext.add(background)
Because javascript is what is going to load the final template into the view, what is the recommended way for me to get the data for that template, should I query the database from the front-end by setting up special subscriptions?
Typically I render the data into the page from the router on the server but...
with famous, I just have to load the main template and let famous load the rest of the templates. The only thing left is getting the data for the other templates. What is recommended?
I would start by looking at https://github.com/gadicc/meteor-famous-components/. That package will do all the work for you if you want.
I have never used the Surface template argument but I believe that is a one time load and will not update on data invalidation (data change).
Or u can take a look at working examples )
https://github.com/sayawan?tab=repositories
I am using i18next package for NodeJS to enable translation. I am using it as standard with a json file for each language-COUNTRY pair.
I'd like to build an admin page to edit translations without having to dig into the code; then, how can I "reload" the json files once edited by admin, without having to restart the server ?
Also, is it possible to use a DB (i am using mongodb) instead of JSON files ? Would it be more appropriate in this case?
I wish i knew the answer to how to reload the JSON files without completely re-initializing i18next-node.
In terms of storing your translations in a database, i18next-node can connect to MongoDB (as well as Redis and CouchDB): http://i18next.com/node/pages/doc_init.html#backend
You can set
i18next.sync.resStore = {}
and then call
i18next.init(callback)
to force a reload of your preloaded languages.
It is better to use an official API of i18n with reloadResources.
// reload all
i18next.reloadResources();
// reload languages
i18next.reloadResources(['de', 'fr']);
// reload namespaces for all languages
i18next.reloadResources(null, ['ns1', 'ns2']);
// reload namespaces in languages
i18next.reloadResources(['de', 'fr'], ['ns1', 'ns2']);
I'm getting started with ServiceStack and I've got to say I'm very impressed with all it has under the bonnet and how easy it is to use!
I am developing a predominantly read-only application with it. There will likely be updates to the database 3 or 4 times a year but the rest of the time the solution will be displaying data on an electronic information board (large touch screen monitor).
The database structure is well normalised with a few foreign keyed tables and with this in mind I think it may be best to separate the read only API from the CRUD API. The CRUD API can be used to create and modify the relational data with POCO classes matching the database tables. I would then ensure the read-only API flattens the relational data into a few POCOs spanning a few db tables making the data easier to handle on the read-only UIs.
I'm just looking for ideas and advice really on whether this separation of concerns is wasted effort or if there is a better way of achieving what I need? Has anyone had similar thoughts / ideas?
Having developed a similar read only application (a gazetteer, updated quarterly/yearly) using ServiceStack we went with optimizing the API for reads, making use of the built in caching:
// For cached responses this has to be an object
public object Any(CachedRequestDto request)
{
string cacheKey = request.CacheKey;
return this.RequestContext.ToOptimizedResultUsingCache(
base.Cache, cacheKey, () =>
{
using (var service = this.ResolveService<RequestService>())
{
return service.Any(request.TranslateTo<RequestDto>()).TranslateTo<CachedResponseDto>();
}
});
}
Where CacheKey is just:
public string CacheKey
{
get
{
return UrnId.Create<CachedRequestDto>(string.Format("{0}_{1}", this.Field1, this.Field2));
}
}
We did start creating a CRUD / POCO service, but for speed went with using bulk import tools such SQL Server DTS/SSIS or console apps which suffices for now, and will revisit this later if required.
Might want to consider something like CQRS.
https://gist.github.com/kellabyte/1964094 (or Google for CQRS Martin Fowler, can only post 2 links).
Also found the following article valuable recently when starting to implement additional search type services: https://mathieu.fenniak.net/stop-designing-fragile-web-apis/