I like MongoDB ok, but I was thinking about just using postgres as the read model and querying from it with graphQL. Do I have to write an adapter to do that? If so, where should I look to start?
As always, it depends 😉
Short answer: No, you can't.
Long answer: Yes, theoretically changing the read model database is possible, as wolkenkit uses an adapter-based approach. Right now MongoDB is the only implemented one, but it would be possible to write one, for whatever datastore you want to use.
Basically, the place to start is the wolkenkit-broker, which is the public API server for wolkenkit, and which also handles reading models. At the center of this there is the so-called modelStore, which acts as an abstraction layer over the specific implementation, such as the modelStoreMongoDb adapter.
GraphQL again is currently not supported out of the box. We use our own approach, implemented in the tailwind module. The place to start here is the HTTP server API.
Please note that I am one of the developers of wolkenkit, so please take my answer with a grain of salt.
Related
I have two separate cloud-based APIs that I am working on integrating together. Neither software directly talks to each other so I am creating something in the middle to get them to communicate. I have had trouble finding examples or documentation on how exactly to do this, does anyone know of any resources that could help me out?
My plan going in was to use a MERN Stack, running on a local server to do GET and POST requests to both APIs, use some mapping and logic to transpose the data into the correct format and send it to the other software. I do not have a client per se (other than myself) on my end, so I really will be skipping the React part of MERN, at least that is what I'm thinking. I'll be using Mongo to keep track of both sets of data for redundancy. I also considered using a LAMP Stack but felt that MERN would be faster in handling the data, and Mongo is more flexible in handling different data formats. If there is another process or technology that could help me that I'm not thinking of, I would be grateful to hear about it.
Has anyone encountered something like this before? Thank you.
As with most architecture questions, there's no completely right or wrong answer here. You could certainly design a well-built system to handle for this purpose with either stack; even more-so when you mention that your front-end framework is not an important consideration. Instead, ask yourself questions like this:
Which stack do you have more experience with, and is this an appropriate time to learn a new set of technologies, or is it important to do the best work you're capable of right now (how important is time, cost, or quality in this case)?
Another generalization I'll stick my neck out for is a data-first approach; what sort of data are you dealing with from each cloud integration, and what kind of data do you need to support and/or create in order to make your system work? Mongo, being a NoSQL persistence layer, will allow you to change your data model and handle more varied data in a quicker and easier manner than a SQL solution will. This is a double-edged sword, however, as lack of validation and a strongly-constrained (typed?) data model will make your application harder to work with and debug as it grows. In short - how big might this application grow?
If you have a handy and familiar way to manage the three different data models you're dealing with (cloud service 1, cloud service 2, and your app) via MySQL, then that's a compelling reason to use it. However, if your style is to start dumping data into your database and you're comfortable with a more iterative approach (which may require more, albeit shorter rounds of refactoring), then Mongo with MERN may be the preferable choice.
Finally, will others ever be working on this application? If so, which language would you prefer to be dealing with them upon - PHP or Javascript?
I'm interested in using PouchDB for a offline-first mobile application (Cordova) and I'm wondering if there is any leightweight ORM/ODM for PouchDB written in JavaScript. Couldn't find one.
Is PouchDB the most common way to implement "offlinability" in JavaScript? Or are there other better ways to do that (without going native).
Another one is https://github.com/iyobo/pouchorm, claiming to be 'The definitive ORM for working with PouchDB. Native support for Typescript.'
At the time of writing it appears to be still actively developed.
I did some research and consider PouchDB and RxDB the two most feasible options if you go for open source and want to avoid larger costs for the servers. There still is CouchBase which provides libraries for many languages.
PouchORM (https://github.com/iyobo/pouchorm) is a solid option.
It's light weight and yet super-functional.
It has all the features I would care for when using pouchdb; namely it's simplicity, data validation and it's cool use of separating data across a single DB using collections.
The collections are also indexed by their type so this does not affect speed.
I can't find any information on initalizing a couch db. What's the best method of initializing and creating the map and view functions for couchdb at deployment?
I have a node server which will access a couchdb. Should I just create the http calls necessary to create the proper logic on couchdb from my node server or is there a better way handling the initialization of the db?
EDIT: Also is there any good open source projects that I can take examples from?
I'm not sure your question is clear. Remember that CouchDB is schemaless, so, at startup, there probably isn't anything (ie, documents) on which to base view functions.
If you mean a helper to setup a design document with attachments and the like, in addition to the other answers, have a look at Kanso (http://kan.so). If you're comfortable with Node, you'll find it friendly.
If, on the other hand, you're looking for something to analyze existing docs in a CouchDB and guess at good views, I've haven't come across that yet.
One possibility would be to use erica.
Is there a mock backend for CouchDB, i.e. same REST interface and semantics but purely in-memory? We have a testsuite that runs each test on a pristine database every time (to be reproducible), but running against real database could be faster.
Do you mean running against a mock database?
I do not think there is something right out of the box. Two ideas:
CouchDB on a memory filesystem. Set up a ramdisk, or tmpfs mount, and configure the CouchDB database_dir and view_index_dir to point to there.
PouchDB is porting CouchDB to the browser IndexedDB standard. You did not say which language and environment you are using, but if you can run Node.js, this might be worth looking into. PouchDB has good momentum and I think it will be running in Node.js soon (perhaps through jsdom or some other library. Note, this does not get you the full solution; but you have expanded your question to "are there in-memory IndexedDB implementations for Node.js" for which the answer is either "yes" or "soon," given its adoption trajectory.
Found this: https://github.com/RipcordSoftware/AvanceDB - it supports different platforms and seems to be a serious effort.
Rather late to the party, but I've had great success using pouchdb-server, based on the aforementioned PouchDB project (a JavaScript implementation of CouchDB). It can run against a variety of back-ends, including an in-memory back-end. That means you can run
pouchdb-server --in-memory
to get an in-memory CouchDB-compatible server. There's several other command-line options to explore, too.
I think it is able to run the entire CouchDB test suite, so I'd guess it is fairly unlikely you'd run into too many implementation differences.
I have the same problem... for tests i just don't want to setup a couchdb... i just want to have some memory stuff, as easy as possible.
What did i do:
* I create a memory CouchDB Connector => it's just a very simple implementation of "org.ektorp.CouchDbConnector"
* By spring i wire the CouchDbConnection-Implementation which i need => when i use it for my dev-tests i wire my memory CouchDB Connector, if i want to connect to a real CouchDb i use the usual connector => org.ektorp.impl.StdCouchDbConnector
The only problem is, that "org.ektorp.CouchDbConnector" has more than 50 methods, which must be implemented. For my issues it was enough to implemented just a few of these methods. Depends on your testcases.
memorydb is a partial (in-progress) in-memory implementation of CouchDB to be used with Kivik, which can be run as a stand-alone server.
Not all functionality is implemented yet.
How to connect nodejs with solandra?
If it's possible provide some example code
I want to learn nodejs with solandra.
provide some sample code or some urls
Since the Casandra side of Solandra is really just a rework for indexing purposes I'd expect that the Solr interface should still be in tact.
Therefore, you probably want to take a look at https://github.com/gsf/node-solr.