-2

I recently wrote a data management tool in Python & SQLAlchemy. Now, I need to put a web UI on it. While I want to start small, there is some need for interactivity, like drag and drop in tables, that I can't do in 'plain' HTML / CSS. It seems to me that there are two basic paths I can take from here and I'm not sure how to choose the right one. As I see it, both paths involve Flask and they are:

Develop my UI with

  • Flask, embedding Javascript where needed to provide the interactivity I need, or
  • Develop the UI in Javascript, having it call an API I develop using Flask with Connexion and Open API

Today, someone suggested to me that it would be easier to develop the UI in Flask and that, as I'm doing that, adding an API for others to get to my app would be relatively simple, giving me both a UI AND a platform for writing a pure Javascript UI application.

I know Python and databases. I don't really know HTML / CSS / Javascript and will likely have someone else write that part for me, wherever it sits.

Does anyone have any suggestions as to what would be the best way to get something done quickly while retaining long term flexibility? Thanks for your help!

Ben
  • 115
  • 4
  • 1
    Not sure why the downvote. Is there a better forum for a question like this? Stackoverflow seems focused purely on code issues. – Ben Jun 30 '20 at 20:41
  • 2
    Yeah, I think you asked a completely valid, question, which I have tried to answer below, I also had the same question earlier in my programmer journey. In an act of solidarity I have given your question an upvote, hopefully your question gets more upvotes and we can outnumber the downvoters :) – Tomiwa Jun 30 '20 at 21:27
  • 1
    @Tomiwa Thanks! I'm afraid I take my downvotes too seriously :) – Ben Jun 30 '20 at 21:40

2 Answers2

2

I would recommend you go with the second option: Use Flask for the API and use a javascript framwork like React for the UI component.

See seperation concerns (on wiki and stackexchange) for more information about this.

The reason for this is that Flask is good for API related tasks and React is good for UI related tasks. Once you start trying to get Flask to do things that React was literally created to do, you end up reiplementing functionality that React already has built-in.

The fact that you mentioned that someone else will be writing the UI code, makes using a frontend framework extra important.

Having the two operating independently ensures that you build your Flask API in a RESTful way that allows other clients to communicate with it instead of having the UI tightly coupled to the API.

I wrote about why I used Django and Angular to build a web application which might be useful to you. Though, that article is now outdated because in hindsight, I should have used React and I did end up switching from Angular to React.

I also, used Django instead of Flask because my use case required more features than simple Flask offered e.g. User authentication, ORM + postgres support etc. But Flask is still a good choice for smaller APIs and I also use Flask for my web app's microservices.

Hopefully you found this useful, feel free to ask follow up questions in the comments and I wil be happy to answer.

Tomiwa
  • 136
  • 3
  • Thank you so much for the details, Tomiwa. FWIW, I tried Django a few years ago but, being much stronger in SQL than OO programming, I got sidelined by the ORM (rightly or not). Flask with SQLAlchemy gives me a balance between UI and SQL that I find comfortable. – Ben Jun 30 '20 at 21:46
1

I'm at that exact same situation you seem to be.

We're decided on HTTP for the majority of the app and WebSockets to handle more real time interactions.

We're keeping as much in the HTTP side of things as we can. But the majority of the essencial features are handled over a websocket connection using transactional state management (see flask-sockets). Essentially clients post some request, and the answer may be broadcasted to other clients.

As for javascript (not our cup of tea) we're following a dead simple MVC structure that is working very well. You may check our proof of concept for the conceptual design in gitlab.com/prodrigues1990/snake, although I'm not sure how much you would get from it without having been part of the meetings. The concept is an example of the well known snake game. Just following what we expect to be our interface model. But you will have to imagine the network part, which right is resumed to a reducer function (to be replaced with actual web socket events).

Pedro Rodrigues
  • 296
  • 1
  • 8