Our company start a new project that will need some web rest api. Recently we are using Laravel, but in some cases it is pretty slow difficult to speed up (Caches, Optimising queries .. ). We have basic - medium experience in cpp, so we are interested in speeding up api calls in new project by using cpp. Very interesting were projects PHPCPP or CPPREST with which we want to experiment. Which one (or some other) would you choose and why?
Project will have pretty big database and various structures, so we are thinking, if to somehow use Laravel with PHPCPP and mysql DB (DB calls will be done by cpp, so eloquent is a little useless) or CPPREST with sqlite.
Related
I have a number of tables inside a database that I use for 4-5 different websites. These tables already exist and have plenty of data and views/stored procedures/functions etc. already completed.
I would like to provide an api to give access to each of these tables to whichever website I happen to be using so they're accessing the data in a consistent manner. I have Visual Studio 2015 and have been trying to create a Web Api using EntityFramework.
However, every tutorial I find for accessing databases insists on creating the database and tables within the code for the api, and utilizes just the tables with the various CRUD actions handled within.
As I have the tables built, I don't want to recreate them, and as I have some programming already in place using functions/stored procs, I don't really want to reinvent the wheel and recreate it all.
I did find this: http://www.c-sharpcorner.com/UploadFile/4b0136/working-with-stored-procedures-using-entity-framework-part/ for EF6 (though I believe I'm using EF7, but that seems to be importing each function in turn, which seems.. kludgy)
So my question is two-fold:
Is ASP.NET 5 web api the right tool for the job?
Can the ASP.NET 5 web api handle stored procedures easily?
At time of writing it's currently easier to build an API over an existing database using ASP.NET 4.6 and EF 6. This tutorial describes how you can go about building a model from an existing database:
http://www.asp.net/mvc/overview/getting-started/database-first-development/creating-the-web-application
Once you have a model and your classes in place, you can then follow any article on scaffolding Web API.
I recently started using RavenDb. I am converting a relational dbase to use RavenDb. I have two simple tables in the Relational dbase:
tbStates
tbCities
I have all US cities linked to a state. How can I go about converting this to no-sql. Will I have to write a little application to read from the relational dbase and create the objects? Or are there some tools out there I can use to do this?
There is a utility called smuger http://ravendb.net/documentation/smuggler but I imagine you will have to convert your data to Json. It may be just as easy to write a console app that reads the tables to objects then loads to Raven.
Just to add I migrated a SQL Server database to RavenDB using the console application route.
I used EF to quickly pull out the data and converted it to my RavenDB domain then added it to RavenDB.
It Worked well as you will most likely want to tweak the domain anyway to work best with RavenDB (For example I had an Images SQL table that I turned into a List on the document etc).
See Ayende's RacoonBlog project on github (https://github.com/ayende/RaccoonBlog) as he does something similar to move subtext data to RavenDB. RacoonBlog is the engine powering his blog and makes for good learning material about how to use RavenDB.
Okay, so I'm currently developing an iphone app that I plan to take into production and scale. I'm a bit lost on the whole subject.
What is better to use: core data or sqlite? (as the local DB)
Also, can sqlite be used exclusively to communicate with my remote server as well? At first I thought it could but I've been reading that sqlite isn't great to use on servers that get a massive amount of hits.
I've read that oracle, mysql, or mssql may be better to use on a remote server and that I can communicate with these servers via REST or SOAP.
I plan to be able to both read and write to a remote server. The files transferred will mostly be small data objects and pictures. Speed is of the essence, so I'd like to know which options are my fastest routes. Of course, I want the option to scale and not have performance take too much of a hit as well.
On the subject of Core Data vs sqlite see this question.
SQLite is a small and lite embedded SQL database engine. It's not meant to used in server environments. In general, it's not a good idea to communicate directly over the Internet. It's more common to have some sort of process logic between the client code and the database to do a range of things like validate input, process business logic, security, etc. You can implement this sort of layer in REST, SOAP, or whatever you like. Since your clients will be mobile devices, a http based web service (like REST or SOAP) is a good idea as all mobility platforms have inbuilt API support for http messaging. There are lots and lots of options on the server depending on what type of server you want to setup and run with.
If your new to this, maybe you should read something like 'Patterns of Enterprise Application Architecture' by Martin Fowler to get a idea of what sort of design patterns people use to implement the server side layering.
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).
I've prototyped an iPhone app that uses (internally) SQLite as its data base. The intent was to ultimately have it communicate with a server via PHP, which would use MySQL as the back-end database.
I just discovered Google App Engine, however, but know very little about it. I think it'd be nice to use the Python interface to write to the data store - but I know very little about GQL's capability. I've basically written all the working database code using MySQL, testing internally on the iPhone with SQLite. Will GQL offer the same functionality that SQL can? I read on the site that it doesn't support join queries. Also is it truly relational?
Basically I guess my question is can an app that typically uses SQL backend work just as well with Google's App Engine, with GQL?
I hope that's clear... any guidance is great.
True, Google App Engine is a very cool product, but the datastore is a different beast than a regular mySQL database. That's not to say that what you need can't be done with the GAE datastore; however it may take some reworking on your end.
The most prominent different that you notice right off the start is that GAE uses an object-relational mapping for its data storage scheme. Essentially object graphs are persisted in the database, maintaining there attributes and relationships to other objects. In many cases ORM (object relational mappings) map fairly well on top of a relational database (this is how Hibernate works). The mapping is not perfect though and you will find that you need to make alterations to persist your data. Also, GAE has some unique contraints that complicate things a bit. One contraint that bothers me a lot is not being able to query for attribute paths: e.g. "select ... where dog.owner.name = 'bob' ". It is these rules that force you to read and understand how GAE data store works before you jump in.
I think GAE could work well in your situation. It just may take some time to understand ORM persistence in general, and GAE datastore in specifics.
GQL offers almost no functionality at all; it's only used for SELECT queries, and it only exists to make writing SELECT queries easier for SQL programmers. Behind the scenes, it converts your queries to db.Query objects.
The App Engine datastore isn't a relational database at all. You can do some stuff that looks relational, but my advice for anyone coming from an SQL background is to avoid GQL at all costs to avoid the trap of thinking the datastore is anything at all like an RDBMS, and to forget everything you know about database design. Specifically, if you're normalizing anything, you'll soon wish you hadn't.
I think this article should help you.
Summary: Cloud computing and software development for handheld devices are two very hot technologies that are increasingly being combined to create hybrid solutions. With this article, learn how to connect Google App Engine, Google's cloud computing offering, with the iPhone, Apple's mobile platform. You'll also see how to use the open source library, TouchEngine, to dynamically control application data on the iPhone by connecting to the App Engine cloud and caching that data for offline use.
That's a pretty generic question :)
Short answer: yes. It's going to involve some rethinking of your data model, but yes, changes are you can support it with the GAE Datastore API.
When you create your Python models (think of these as tables), you can certainly define references to other models (so now we have a foreign key). When you select this model, you'll get back the referencing models (pretty much like a join).
It'll most likely work, but it's not a drop in replacement for a mySQL server.