There are similar posts like this on the internet, but they seem to be targeted towards lower level languages like Java. NetBeans for example seems to have this kind of functionality.
Here is what I want to do:
I have a large dataset of items. I want to create a RESTful API that would enable my users to perform complex queries to retrieve data from the MySQL database on my backend.
The API needs to be able to:
SELECT a table to retrieve values from
Be able to use common MySQL aggregate functions such as COUNT, SUM,
and AVG on the results
Create WHERE conditions
Security is not an issue as this my simply an MVP for now. On a future iteration I will take security into consideration. Are there any Ruby gems which provide a framework for constructing this kind of system?
I am open to using either Sinatra or Rails for this system.
Maybe this can help you:rails-api
Rails::API is a subset of a normal Rails application, created for
applications that don't require all functionality that a complete
Rails application provides. It is a bit more lightweight, and
consequently a bit faster than a normal Rails application. The main
example for its usage is in API applications only, where you usually
don't need the entire Rails middleware stack nor template generation.
or you can use grape gem.
Related
I would like to build a mobile version of a household financial planner web app that I built with MVC, C#, MS SQL, and Entity Framework. What I've learned from my research is that I should communicate with the database for this project using API endpoints. I am familiar with setting up a WebAPI with MS SQL, but not MySQL. Also, the little work that I have done in that field was based on only retrieving information from the database. Not adding application users, roles, or any rows to tables. The web application that I'm trying to base this Xamarin application is at http://abacus.travismcdaniel.me
I have been unable to find a guide our tutorial that teaches what I need to know. In fact, most of the guides I've found are so outdated that I can't follow the steps because the things they say to do simply don't exist anymore.
So my question is this: It's there a n up-to-date guide anywhere that can walk me through the basics of setting up a MySQL database to use with the app that I'm building, then walk me through writing stored procedures, seeing up WebAPI endpoints for those stored procedures, and then incorporating all of that into a Xamarin Forms application?
If there isn't one single guide that does this, are there a few (still up-to-date) that I can work through to get the same information? Thank you in advance.
Intro:
We are redesigning our application architecture and we are about to make import design decisions.
Background and dependencies: All data is stored in distributed MySQL databases. We have two systems that access the databases - one that performs routinely tasks, programmed in Java and our web application - currently Apache2, PHP (Zend1 framework) and JavaScript (jQuery).
The Java app will not be redesigned and the database should remain MySQL.
The web application is supposed to be changed to a REST API and a modern, fast, real-time AngularJS frontend that communicate over JSON.
Since we already programmed all backend functionality in PHP, it would probably make sense to stick with PHP for the REST API - but this is not a must if it makes future development easier, faster and future-proof.
The Java app and the web application share some MySQL queries.
Questions:
Shared MySQL queries: Should we implement them as a) MySQL procedures / views, b) separately in Java and PHP, c) independent service (e.g. another REST API)
Should we stick with Zend1 or rather use a more suited PHP REST framework (such as Slim or Restler or something else)?
Should we stick with Apache2/PHP for the REST API at all (maybe use Node.js instead)?
Thanks!
This post is probably designed to start a flame war... but...
Never rewrite code from scratch. Take what you have, and refactor it to create modern restful services on top of it.
Do it as a slow migration, rewriting one page at a time in a like-for-like manner.
You will have far fewer bugs, it will cost less, and totally avoid second-system syndrome
I'm about to port an Android-Travellog App to other Plattforms using Sencha Touch.
The Problem is, that Sencha only has a Store System to store Data, but doesnt appear to have a possibilty to acctually make MySql queries.
And since most of the Mysql code in my previous app is already there, id would be quite a pain to redo everything with Senchas new System.
Is there a possibilty to use mysql (or any other sql) queries with Sencha to Store Data on the Phone?
Sencha stores and proxies abstract away the need to write raw query code. A store can use one of a number of different proxies for interfacing with different back-end data stores, one of which is the SQL proxy, which as you can see in the source code provides an API for basic data querying WebSQL databases.
If you want to gain the full benefit of the framework and do things the "Sencha way" you'll probably want to start from scratch and architect your app to use the stores API.
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.
I intend to have multiple Rails apps each for site.com, api.site.com, admin.site.com. All apps will access the same tables from one single MySQL database. Apps and database runs in the same server.
Is there any settings in Rails, ActiveRecord or MySQL that I need to be concerned about for above access scenerio? Thanks
Running: Rails 2.3.5, MySQL 5.0, Nginx, Passenger, RubyEE
This configuration tends to be quite difficult to maintain.
In every app, you would need to keep schema.rb and models in sync in order to use the same database. It means lot of duplication.
This isn't probably a good idea. Instead, you might want to design the application to meet one of the following scenario:
one Rails application which handles site.com, api.site.com and admin.site.com (why do you need separate app?)
multiple Rails applications, but just one interact with the db. The others uses the main application API (quite complex)
different apps with different purposes (for instance, you might want to use Sinatra + Datamapper for api.site.com)
The first option is probably the best one in most cases.
I answered similar question here. You can do it and sometimes it is reasonable.