App structure - Business logic inside pages?

Ionic Framework ionic-v3
1

Hello guys,

This is my first post :slight_smile: . I would like to discuss whether it is appropiate to put business logic in Ionic pages. I’m new to Ionic and having been playing with it for a couple of weeks I have some doubts regarding app structure.

I’m currently trying to implement a small app that consumes a REST API. Having stopped to learn Angular first for a week before starting with Ionic, I learned that Angular Components should not have any heavy business logic inside them, as they are meant to be as simple as they can get, so modularity is not compromised. Services in Angular are the ones in which the application business logic relies.

I come from a Java background and I have some experience developing native Android, in which each page (activity or fragment) has it’s business logic implemented right there.
Now for me it’s a bit confusing, AFAIK Ionic pages are Angular Components in the end, but it would be familiar for me to put business logic into them, sadly I don’t really know if I should… Let me give you an example, I ran into this situation:

I have a login page, which should log the user in and store some data coming from the server with the response to the LOGIN request. Here you can think of two Angular services to use, one is the UserService, providing user related functionality and the other would be the StorasgeService, providing storage functionality.

Here would be the application flow:

  1. User enters credentials and clicks LOGIN
  2. App fires a POST request to /login with username and password
  3. Auth OK @ backend: Server responds with a token which the app receives
  4. App stores the token in the device
  5. App asks for user info using this token received with a GET req to the server
  6. App receives user info and checks if account is confirmed
  7. If account is confirmed, you can continue to the next page. If not, an error message shows up

Thinking of this application flow, I am tempted to implement all this business logic inside the LoginPage.ts*. This page relies on UserService and StorageService to make requests to the server and to store the token inside the device, respectively, but the business logic is implemented in one method inside the login page TS file.

I don’t know if you think this approach is acceptable or if it would be better to have a “doLogin()” method inside LoginPage.ts which only called a login() method in UserService and then implement all this business logic inside that Service.

I hope I could explain myself well and very much thanks for your time!

2

Store salted password hashes in the backend. Hash the plaintext password on the device before sending it. Otherwise your user’s authentication data is visible over public wifi.

If you want to put all the logic in a single method, find a company that provides auth as a service, like Ionic or Firebase. If you want to roll your own authentication (and from your OP, it appears you are not prepared to do so, you would need to do a fair amount of reading first), then you need at least one provider to handle security etc.

3

Hello Aaron and thanks for your reply. Yes, I’m aware of the security concerns my OP has, as this is a very simple example in which I try to illustrate a situation where I need to choose where to implement my business logic: The page typescript file or inside an Angular service.

I know that for the real world this wouldn’t fit. It’s just an example to discuss where I should put all this logic. For the real world not only salted hashed passwords would be needed, but also securing the API endpoints with a token based approach. I have already worked with Certificate pinning vía TLS, JWT, Android’s Account Manager and Spring Security to archieve it in a banking application before.
As I mentioned, security or the application flow is not the question here, what I wanted to clarify is if I should or not place heavy business logic inside pages or just rely on services :slight_smile:

4

What you describe sounds fine to me.

Stuff that is used in multiple places of course should go into services, for stuff that is only used in one page, you can still decide if it is worth the additional work to extract it into a service if you think you have “too much” code in there - whatever “too much” is for you.

Having it in the page itself can be nice as it all in one folder, together with the template and styles. Having it in a provider can be nice, as it is more seperated and you can seperate the “dirty” stuff from “clean” logic/flow stuff that stays in the page.ts

5

Sort of by definition user authentication is something that is used in multiple places, so I strongly believe the bulk of its logic should be done in a provider, not a page.

6

I don’t really know if this logic will be reused, I don’t expect it in the short term, as the application has a well defined entry point for authentication: The login screen. Once user has been logged in, the application should download the user’s info from the server and store it so login is not needed again unless the application is uninstalled.

The app won’t try to login the user again, kind of the functionality provided by whatsapp or telegram, in which once authenticated and phone number verified you don’t really have to authenticate again as long as the app remains installed on your device.

Anyway thanks, I think I see the point now and understand that business logic is OK to belong inside pages as long as it is not reused, in which case a provider should be used. I’ve also noticed this difference in terminology: service (Angular) vs provider (Ionic).