I'm building an app, with Sencha Touch and NodeJS as a backend. This app is supposed to be used to control and report the whereabouts of public transport in a city. I'm planning to have three modules built, one for the passenger, one for the driver and one administrative module.
What I'm thinking is, should I build all these modules in the same app and check for user profiles at log-in? Or should I build separate apps (at least to separate the general user module from the other two) to make it more secure.
If the passenger somehow got access to any of the other modules it would obviously be extremely harmful.
The first reason to have 3 different modules is what you have pointed out - security.
The second reason to do so is - what if one of the services fails - as 1 large codebase it brings the whole lot down - as 3 different services, 66% of your service is still working.
The third reason is KISS - keep things simple stupid - one big codebase is harder to reason about and model. Bugs affect the whole codebase. Adding features becomes a trade off between the services.
Generally I would say to not only split your app into 3 modules but to take this approach down to a much lower level and try to split things into 'single components' as much as possible.
Think about a carpenter making a table to order (what most software devs are doing is 'to order').
The carpenter does not download a 'table making' library as one large codebase.
They first use the 'saw' program to saw wood.
Then the 'sanding' program to smooth wood.
Then the 'Hammer' program to put wood together - etc etc
Notice how each step is one tool doing one job.
The next day the carpenter is asked to make a chair - they use the same tools in a different order.
This is the Unix Philosphy
I would say that dividing the access to different information is an application layer concern and I would build it all into the same node.js app. This app should check with the user permissions if that type of user has access to the information it is requesting.
Related
First of all, I'm not really sure if this question goes here in stackoverflow or if I should ask it on another place. Please if that's the case, indicate me in the right way :)
So, for context, this is an app that I was asked to develop for my job. At first I thought in doing a webapp and host it inside the company servers and domain (intranet), but it isn't possible due to external issues that I can't control.
Is there another way to achieve this? The app must have a database and should be accessible for a bunch of users at the same time.
Of course we want to spend the least amount of money possible to make this happen. Also, using a workstation of our own to host everything is not possible either.
Edit: I didn't finish developing, but for now I'm developing it in Python Flask.
The number of users is small really, just up to five people.
OK - I guess a lot of what you'll get in response to this is your definition is too vague. Things such as scale, number of users, programming languages used to create the web app etc are important when talking about hosting.
However, for me, there are three very good options out there for free hosting, up to a certain amount of traffic.
1.) Heroku - Heroku.com
A world known web hosting platform. You can publish code through GitHub, and it has some extensive coverage for different types of web apps. Definitely worth a look.
2.) Netlify - netlify.com
Similar to Heroku, but used by some major companies. Allows you to host for free to a point, and is relatively simple to get started with.
3.) Vercel - vercel.com
A bit more technical in my opinion - but again, very similar to the above two and has a free tier.
All three are great options, and I'd recommend looking into them in more detail to see what option is best for you. Can't go wrong with any of them.
I had a similar problem: A Python-Flask-SQLite app for me and my office pals to use together.
The solution was creating one .exe file with pyinstaller, hosting this and the database files in a network drive (one that everyone that will use the app has access). As everybody (~10 people) sees the same db, things works fine!
I have developed a program using curses, everything is cool so far but I was wondering myself if there is a good pattern to split different views/panels of my program into smaller chunks callable by my main loop?
Further informations:
This program is a rather small automation tool/wizard aiming to ease our application for customers requiring the on-premise installation.
This wizard is a 3 steps one and it’s used to grab informations from our customer installation needs depending of it’s chosen architecture.
The first step is requesting the customer to give us its identification informations such has contract number, company name, licence number and preferred contact.
The second step is requesting the customer to give us informations about either he want a standalone installation (All-In-One install) or a N-Tiers installation plus the required informations like the requested custom SSL VHostName or Tiers IP/Credentials.
The third and final step is showing the customer a progress bar and informations of the required services (MySQL/HTTPd/HAProxy/PHP-FPM) and our application.
I know that I do not especially need to use curses library for such a program but our UX Team requested it as it is part of our customer experience with the solution.
You can look at the Forms library. It's a nice extension to ncurses that allows you to better manage input forms like yours. It offers a simple function interface to read the fields, change their properties, etc., as well as many different field types (including regexp-validated fields). In your case, you can simply create three forms, and post/unpost them in succession.
as such way to do things is not really usual, do not expect any framework to be available (like those available for WebUI for instance).
I so decided to create my own "Framework/factory" and so to be able to split every aspect of my app in a logic that would be similar of those used by web applications.
The source-code is dirty and really not pythonic, but it is well working so far and quite easy to maintain.
Thanks everyone for your answers and ideas.
Given a java web application
And that it has a restful back-end
And serves a single page html/js front-end
When I use cucumber to test my application
Then which layer should I drive my tests through?
Possible Options:
1) Domain layer: StepsDefs delegate directly to services and repositories
2) REST layer: StepsDefs delegate to REST client which fires HTTP requests at container deployed app
3) User interface: StepsDefs delegate to web driver such as selenium and manipulate the user interface.
PS) Feel free to write your answer in given-when-then notation :)
I think you are asking 2 separate questions, one in the title and another in the body.
1) What is the 'correct' level of abstraction?
Executable specifications should be written in the domain/ubiquitous language that makes sense to all the relevant stakeholders (especially non-technical). Each scenario should usually validate a single behaviour and the text should include only relevant information - redundant or incidental detail should be omitted.
The test for correctness is "are the people reading this scenario interested in it?" If the answer is "yes", you will probably be getting valuable feedback from them. If the answer is "no" then you need to collaboratively refine your domain language and focus on behaviours that do interest them.
You may find that you have various stakeholders that have different interests. That's fine. Separate the scenarios into different feature files, each targeted on a segment of your stakeholders. Think of these as different levels of details within a large printed manual.
Any tests that the technical team want to write that no non-technical stakeholder seems interested in can be written using your favourite "unit" testing framework. You could use Cucumber/Gherkin, but is the cost of maintaining domain language for these test worthwhile? You need to decide.
2) How should the StepDefs interact with the application?
This question is orthogonal to 1). And the answer is, as always, it depends. I apply the testing pyramid approach and favour tests that exercise as little of the application as makes sense. If I'm testing the behaviour of a component I'd like to interact just with that component through the simplest interface it presents. As I move up the pyramid, I start testing protocols between components, and finally I'm ensuring that the whole application has deployed correctly and 'hangs together'.
Sometimes the only interface available is the UI. That sucks, but we have to live with it if that's the way the application has already been built. This often leads to slow and brittle executable specifications that need significant maintenance. Next time, drive the development from the outside and ensure you have ways of exercising the application underneath the UI.
A technique that #everzet and I arrived at from different directions, is to use tags to alter how StepDefs interact with the application. The domain language remains unchanged, but the tag signals to the test code whether it should interact through the UI, the REST API or direct calls to the code.
He has documented his approach in "modeling by example". I used the same technique in the opposite direction to rebuild trust between dev & test and described in The Cucumber for Java Book
Sorry if this is not a place to ask these questions. But I just want to know if...
Can JHipster go large scale applications?
Is it possible to minimize the generation of codes especially with the UI part?
Can I extend some RestController class that has been generated to. (Like a custom model class where in I get base64 string to write in a file)
Sorry again for asking, its just that I'm building a startup business and I want to know if these are all possible. I can't help but to get over excited on JHipster and I'm literally crossing my fingers now!
Thanks guys!
Three questions in one, in fact!
It depends of what you call "large scale". We have users with several hundreds of tables, so that's what I would qualify as "large". Other people use a "micro service" approach, with several JHipster apps working together, and that's what I'd recommend. Our Gatling tests (as well as feedback from users) also show we are able to sustain a large amount of HTTP requests, compared to "competing" stacks such as JBoss or Play! (but both of them don't have default settings oriented towards production, like our "prod" profile - for example they don't have a 2nd level cache enabled by default - so that's normal we are much more performant out-of-the-box)
If you don't like the UI part you can remove it, but in that case I would recommend not using JHipster -> this is the whole idea, otherwise just use a bona fide Spring Boot, or DropWizard
It's just a generator, so yes you can extend or modify anything that was generated
yes you can, i have used it for one educational board who have 20housand+ js file, and also used it for 3 ministry
I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)