Event / Transaction logs

Huy

Hi,
I believe this has been covered before in the last forum space, but I'll bring it up again here.
I come from a more traditional software development background and make extensive use of logs to debug my systems. Xano looks fantastic, but as a new user, and again someone from a traditional developer background, it would be extremely useful to be able to write various data to analyze, review and even debug.

Michael Udinski

Hi  - thanks for including this in the new community! 

This is definitely on our radar as it's been a popular request. It's something we are going to look into adding but we have a few marquee features in the pipeline before we can do that including versioning and citizen developers for the marketplace. 

Huy

Great!
I think from Xano's perspective, basic logging is sufficient.

But for larger scale and more complex systems, integration with something like splunk comes to mind. It's not that one couldn't build more complex systems with Xano. But building is only part of it; once the system is up and running, monitoring, debugging, managing/operating etc. become critical. 

For my use case, its inconvenient. But for larger, truly enterprise systems, its a show stopper. 

Huy

While I'm at it - 

1. step through debugging.
2. unit testing.

Erin Wagner

Amen!

Huy

 
are you operating without logs at this point?

Erin Wagner

 Yes. I'm still in development--hoping to start internal testing soon--but I'm already pretty anxious about the day coming when folks will be using my app and I'll have no clue if it's crashing. A developer friend told me about plug-and-play software he uses that alerts him of crashes--complete with all system info. I can't remember the name, but my ideal would be a simple integration with something like that. Especially if it can cover both the front and back end. (No clue whether it can work with my front end no-code tool: AppGyver.)

Indrek Peenmaa

 I would say that the core benefit of Xano is that it allows you to quickly build business logic and create business value.

Yes, you will incur tech debt by not being able to do everything that large systems require like monitoring, debugging, versioning - but if you use it strategically - running into that debt is good investment.

There is a good article about such trade-offs here.
Point from article - nobody succeeds by having very low tech debt.


    

Huy

 

So here's a workaround. It's not the best, but it's actually a legitimate strategy I've used in previous lives. 

1. create a table called 'logs'
2. recommended columns are time_stamp, function_name (text), log_details (text)
3. wherever you need to track something important (ie state change, value of variables etc), you write from where and the details to the table.

Depending how much data / logging you have (i'm going to have *alot*), you may need to build some kind of front end to select by various clauses (ig. select where function_name=$some_function and time_stamp between $start_time : $end_time and log_details like $someExpression% (where '%' allows you to do some pattern matching))

I imagine one could write to an external API, but that is going to get expensive and add latency.

It's not ideal but should work.  

Huy

 
I hear you. In my use case, not being able to have logs is a show-stopper.

Erin Wagner

 Oh interesting. I was anticipating doing something similar, but as a separate api call to POST to the log table. I appreciate your comment about the expense and latency. I can see your point that integrating the log into the existing action's endpoint will be much smoother. Thanks for sharing!

I will point out to Xano though (  ) that this won't let me know if it's crashing on users. Still really looking forward to that functionality at some point.

Huy

I don't want to presume, but from the naming of the variables, loop construction and programming operations, this is built inside of Postgres. 

Regardless, it will most certainly be faster for you to perform a straight update / add to a table rather than posting through and API call. That would require you to hop through the network stack vs a straight database write from code or (i think...) inside the database itself.

You could make this easier / more convenient too by creating a utility function that takes as inputs the function_name and various important descriptors. It sounds like you have a mobile app so i can imagine user_id off the top of my head. In any case, each time you need to write to the log table, you just stick your helper function in place, pass in the name of the function you're calling from and then any additional information.

But it all depends on how important it is to be able to trace through a series of logic and see where things blew up.

You're right though...this isn't going to alert you when things crash! 
For that, you'd have to set something up to monitor your app. Like pinging an endpoint every 5 or 10 or 30 seconds and confirming you get a response.

gbdoin

Added this thread to the following feature request (upvote if this is important for you)