I am to build a web app and I have realized that my domain data will be best represented by a graph structure. Which web frameworks out there does the greatest job at integrating with graph databases (neo4j in my case) and thereby gives me the easiest time getting up and running? I am open for all languages (mostly..)
EDIT:
My use case:
I am creating a bug tracker for a university department. It will track all kinds of issues (eg.: the classroom 1-0-24 needs chalk for the whiteboard, the course 'Introduction to programming sucks because of...', The alarm on the door into the library is way too strict, etc.)
I have defined loads of 'Areas of responsibility' (AoR) that are related to each other in terms of 'topically relatedness', 'is a super-AoR', 'is a sub-AoR', 'the responsible team is also responsible for this other AoR' and such. I want to present a graph of these areas of responsibility to the user. This is my wishlist for the graph:
Initially only show a subset of the graph
The user can pan around
As the user pans in one direction, new areas of the graph is revealed.
The user can click on a node to a) read more about that AoR, b) assign the users current Issue to that AoR (or maybe even drag issues to a AoR, just like with friends in Google+)
Currently I am considering using Grails (for the non-graphy parts like security and user management) and raw neo4j for the graph parts (that is, not using the GORM plugin that tries to fit a circle in a square hole)
I have now read about InfoGrid and it sounds quite interesting - especially the view-part (though I don't know how close it will bring me to my UX goal). I'm also worryed that it will not be as productive as Grails for the non-graphy parts.
Neo4j doesn't seem completely lost when it comes to visualisation either:
http://wiki.neo4j.org/content/Visualization_options_for_graphs
The InfoGrid project built its own web framework on top of the InfoGrid graph database -- precisely because existing web frameworks don't match graphs very well.
For example, we have custom tags for traversing (simple and compound) edges, detecting certain topologies, converting node identifiers into URLs etc.
Disagreeing with the other commenter, it would be so much harder (and so much less fun) to use a non-graph-aware web framework. We used to :-(
Any web framework you'll choose, should be absolutely independent on the DB integration. From my experience, the best web framework is the one you know the best.
When choosing web frameworks, it is better to consider different criteria than DB integration, (like: public vs intranet application, statless vs statefull model, number of expected concurrent users, etc).
Related
Short Question Description
I have to develop an application for a security company that will store cases of harassment to their clients and cross reference any case with other cases if it detects it is the same person that is attacking them.
These relationships will be used to create a social graph of criminals and victims.
Initially I thought about managing it as a Social Network with some CMS or maybe Elastic Search with some frontend JS Framework but I have only experience with PHP and some basic React/Node.js so I wonder if there is something better that let me make the queries live as users fill in the forms.
Long Question with Use Case Example
Lets say they have two clients: ProtectedPerson1 and ProtectedPerson2
and there is a case saying BadGuy1 threatened PP1 in twitter with the handle #badguy1.
Then another agent that does not know anything about this case enters a new case for PP2, because someone in facebook is posting private photos of the client.
If they start to put the social information and they type #badguy1 or faceboo.com/badguy1 or anything similar the system should ask "is this the same person?" and if the agent selects Yes then both records of two separate cases are related to the same "criminal".
In the end the final objective is to gather all precedents possible to take legal action against someone if is necessary.
Is there any existing Framework, CMS or API that I can use to manage this relationships and create the desired suggestions and graphs?
After further investigation I found that what I really need is a graph database and the one that stands out as the most used one and with better support and integrations is Neo4j (https://neo4j.com) with a front end in React possibly as they offer official driver for javascript.
The time taken to load the charts(visualization) using tableau in my mobile app is close to 10 or 15 secs. So i am looking for alternative methods like creating my own chart but only to use the intelligence tableau provides on creating the visualizations.
In short, i want to know whether there is some support or API available from tableau using which i can draw the visualizations by myself in my mobile app without losing any chart data or functionality like digging deeper in charts.
For example, an API from tableau using which i can create the chart in my mobile app. After creating it, if user touches any data that should be sent again to tableau to get further event action like showing filters/tables etc.
Is this even possible? I did lot of research in tableau and got to know about tableau SDK, tableau API's, tableau extensions etc. but unable to find what i am looking for.
Tableau provides a thorough white paper Designing Efficient Workbooks. I would start by reading that and trying some of the recommendations.
If you are looking for an API driven visualization system, you can check out MuzeJS.
You load your data in an in-browser DataModel, run relational algebra enabled data operators to get the right subset of data, and then just pass to Muze engine, which automatically renders the best visualization for it.
It is similar to the kind of intelligence Tableau provides but since it is a developer first API, you can customize as you want, whether it be for the mobile or the desktop. In fact, most of the charts will be available for both seamlessly.
Any changes to data (including application of data operations) automatically updates the visualization, without you having to do anything else.
Add to that, if you’ve to connect multiple charts (for cross-interactivity, drill-down etc.), you’ve to manually write the ‘glue’ code. With Muze, all charts rendered from the same DataModel are automatically connected (enabling cross-filtering). It also provides composability and the ability to facet your visualization, providing a multi-grid layout.
You can go through some of the examples and the documentation to see if it suits your needs
I am currently looking at various i18n npm packages and most seem to insist that the translations are stored in a flat file, e.g. .json formatted file. My questions is whether this has a performance overhead that would be greater then storing the languages in a database, e.g. MongoDB.
For example, if I have 10,000 translations (we will assume that in this particular application only one language file will be needed at a time, i.e. most will be using the application in English and some users may want to set the application to use a different language.) then this will equate to approximately 200kb of data to download before the application can even start being used.
In a React application, a suggested design pattern is to load data using container components, that then pass data to 'dumb' child components. So, would it not make sense to also load translations in the same manner, i.e. group the translations into usage, or by component, so that the data is sent down the wire only when needed, say, from a call to MongoDB?
I would integrate it in your API. That means you can create e.g. a REST or GraphQL API, which handles this for you. In i18n, it is often reasonable to store the data in a hierarchy. This means you can split your translations in different categories (like pages) and simply request those translations, which you really need.
I really like the way of doing it in the react-starter-kit. In this example, you find how they handle it with a GraphQL API and only request those translations, which are really required for rendering the page. Hope this helps.
Important files of the i18n implementation of the react-starter-kit:
GraphQL Query: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/data/queries/intl.js
Example component implementation: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/components/Header/Header.js
Of course if you have this amount of translations, I would use a database for a better system usage (in the react starter kit, they use simple file storage which is not really usable with so many translations). A mongodb would be there my first choice, but maybe this is only my own preference of flexibility and own knowledge.
Obviously, you don't want each and every language to be loaded on the client. My understanding of the pattern you described is to use a container component to load the relevant language for the whole app on startup.
When a user switches language, your container will load the relevant language file from the server.
This should work just fine for a small/medium app but has a drawback : you'll need another request to the server after the JS code has loaded to load the i18n data.
Another way to solve this is to use code splitting (and possibly server side rendering) techniques which could allow this workflow :
Server builds a small bundle containing a portion of the i18n data
Client loads the rest of your app code and associated i18n data on demand, as the user navigates through your app
If not yet done having a look at https://react.i18next.com/ might be a good advice. It is based on i18next: learn once - translate everywhere.
Your code will look something like:
<div>{t('simpleContent')}</div>
<Trans i18nKey="userMessagesUnread" count={count}>
Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
</Trans>
Comes with samples for:
- webpack
- cra
- expo.js
- next.js
- storybook integration
- razzle
- dat
- ...
https://github.com/i18next/react-i18next/tree/master/example
Beside that you should also consider workflow during development and later for your translators -> https://www.youtube.com/watch?v=9NOzJhgmyQE
I'm in the process of designing a cloud deployed website for a new solution my company is looking to provide. I have been attempting to answer a few questions and haven't had any luck, so when in rome.
First, I don't want the website to be stuck to any one particular framework. I know there is no way to completely future proof a website, but I would rather not put all of our eggs in one basket.
Secondly, I want to have a separation between the front and back end entirely. I have a list of reasons why I'm looking to do this, don't necessarily want to get into the conversation of what they are. Server Side rendering for the most part is out of the question.
So where does that leave me?
My initial thoughts on the design are to have a REST API that can be accessed for any API calls (this may be turned to GraphQL in the future).
The design decisions that I'm mostly wresting with are for the front end. The website will be a dashboard type system, where tenants can log in and see screens for them.
I was thinking that I would have a sort of shell, that hooks on to the index.html. This would have it's own routing, that would render micro-applications that are completely separate from the shell logic.
So for example, if I load index.html, path being "/"
It has some routes that it's responsible for, lets say
"/todos"
"/account"
If I accessed the /todos route, my shell application would then render that micro app. This application would be completely separate from the shell, except some data that might be loaded via the window. Once this application is rendered via the shell application.
So my todos route, for example, could be a redux application that's independent. It could have it's own routing, etc.
Is this is a common architecture? Are there any examples of this? Is there a better way of going about this?
Thanks for any insight!
Sounds like your well and truly over engineering this beast.
You may take on such an architecture for a HUGE build with many dev teams all working separately. Small agile team, the above would create so much overhead in boilerplate and brain ache in context switching between each "app"
Micro-service architecture is seriously great. Just don't break it up too small, read your use case well and break your services up accordingly.
For example: we are a team of 3. We have a pretty large-ish app devised into:
Php API
Backend management interface (redux)
Frontend website (html, react, php)
Search service (elastic search)
Cache (redis)
Data store (mysql)
All on running in multiple docker containers across multiple hosts. Pull down the backend.. Fine the frontend website is still up and running!
I'm considering Wordpress as my CMS platform for a client site I'm doing at the moment.
However, I need to create a couple of custom 'modules'. One of these modules is a form that people will be able to complete and have a quote, and once submitted, in a special place in the Wordpress panel (like a menu or something), there will be a listing of all the submitted quotes (just fetching it from a table in my database).
Another one is to manage a cafeteria menu, so the client can add a different meal to each day of the week.
I know perfectly how to do this kind of things using some kind of MVC framework and doing it 'by-hand', but I'm just wondering if this would be possible to do with WP and if yes, what kind of tools I'll have to use.
Thanks
Quite simply, yes, WordPress would be a more-than-capable asset to your criteria. But it's whether the learning curve in getting to know WP outweighs using a framework you're clearly already familiar with?
Personally, it sounds you like you're pretty solid with PHP, and considering the fact that, in my opinion, what you're planning on doing is relatively easy, I'd say WordPress is an excellent solution.
I'd recommend reading about WordPress 3.0's new custom post type API, and skimming the basics of hooks and filters in the Plugin API.
Submitted quotes would merely be a custom post type. You'd be better off writing the front-end code (like handling the form, UI etc.) yourself, either within a theme or plugin, then using wp_insert_post and let WordPress handle all the database administration. In fact, WP will go one step further and set up the entire admin for viewing, editing and deleting quotes.
Post meta (also known as custom fields) is also there for you if you need to store additional information about a quote that doesn't quite fit the post's table structure.
For the menu, this is even easier. I'd say just create a post category called 'Menu', and the client can publish 'dishes' to it as you would with a blog or any similar rolling format.
I've only licked the surface here. Get stuck in with the above, then check out some other goodies like meta boxes and custom taxonomies!
If you want to try a plugin instead of writing something yourself, Flutter might work. It's a little unpolished sometimes but it makes this sort of thing an absolute breeze.